Что такое SSL сертификат и в чем его опасность. Принцип работы TLS и SSL. Преимущества использования SSL
Live Journal
Facebook
TwitterЭто такой режим соединения с сайтом, когда вся информация шифруется. То есть, например, если вы вводите данные своей банковской карты, то их видите только вы и сайт, который их получает.
Погодите, а обычно разве не так?
Обычное интернет-соединенение проходит примерно через 15 узлов. Например, когда вы покупаете что-то в интернет-магазине, сидя у себя в офисе, отправляемая и получаемая вами информация проходит сразу через несколько узлов:
- Через локальную сеть или Wi-Fi – её может увидеть администратор сети и ваши коллеги.
- Через ближайший узел провайдера – там её могут увидеть сотрудники провайдера, и там же она может сохраниться для госорганов.
- Через региональный маршрутизатор (точнее, несколько) - ещё несколько инженеров.
- И в обратном порядке до сервера, где работает магазин – его узел провайдера, его локальная сеть.
Кроме того, к этой цепочке может подключиться злоумышленник, который будет специально вас слушать. В лучшем случае это будет ваш сосед, который «прослушивает» открытый Wi-Fi.
То есть когда я использую SSL, никто из этих людей не видит, что я передаю и получаю?
Да. Точнее, «снаружи» тогда будет видно только адрес сайта, с которым вы работаете. Вся информация пойдёт в шифрованном туннеле.
Как понять, соединён ли я по SSL?
Самый простой способ, если вы работаете с сайтом, - посмотреть строку адреса.
Если в начале его адреса будет написано https, а не http, то всё в порядке. Эта буква «s» в конце означает «secure», то есть защищённый, шифрованный. Современные браузеры покажут замок около адреса – наверняка вы уже видели такую иконку не раз. Кроме того, большая часть современных браузеров предупреждает о том, что вы передаёте важные данные по открытому каналу. Предполагается, что в будущем большинство сайтов будут работать по SSL полностью. Сейчас же это, в основном, касается только тех страничек, где происходит оплата.
Если я покупаю что-то в интернет-магазине, а сайт без https, это плохо?
Сегодня большая часть интернет-магазинов переходит на шифрованный SSL-канал только для ввода платёжных данных. Более того, для ввода данных банковской карты, например, вас чаще всего перебрасывает на SSL-страницу платёжной системы – чтобы даже владелец сайта магазина не увидел данных, только банк. Поэтому стоит обращать внимание на шифрование при оплате.
По SSL можно соединяться только с сайтом или с чем-то ещё?
Этот протокол обмена информацией используют многие мессенджеры, например, Вотсап, Вайбер, ICQ (в последних версиях), Телеграм, Фейсбук Мессенджер и так далее. И многие приложения тоже, например, банковские. Кроме того, по SSL можно соединяться с чем угодно – это просто способ обмена ключами и ширования, то есть средство построения связи.
Что такое SSL-сертификат?
Когда вы соединяетесь с новым сайтом, и начинаете шифрованный обмен, происходит две вещи:
- Вы проверяете его сертификат
- И меняетесть ключами.
Сертификат в самом простом случае – это удостоверение, что тот сайт – именно тот сайт. То есть, грубо говоря, его «паспорт». Этот «паспорт» подтверждается «нотариусом» интернета – сертификационным центром. Иногда, конечно, сертификационные центры взламывают, и шифрованные данные становятся известны хакерам, но в целом таким центрам можно доверять. На этом доверии держится весь Интернет.
Что за проверка сертификата?
Ваш браузер в начале процедуры установки шифрования смотрит в «бумаги» сайта и проверят его «паспорт». Если там всё в порядке, то вы на современном браузере даже ничего не заметите, и просто перейдёте к следующему этапу. Если же что-то не так – например, сертификат вчера кончился, или он подписан самим сайтом (без независимой стороны) или что-то ещё подозрительно – вы увидите предупреждение.
Почему?
Потому что если сертификат неверно подписан, просрочен или подписан не тем сертификационным центром, который должен там быть - скорее всего, это подложный сертификат, который кто-то заставляет вас подписать вместо настоящего. Конечно, в реальном мире паспорт тоже мог искупаться в реке, потом по нему мог побегать кот, и наконец, на нём мог пририсовать усы к фотографии ребёнок, но обычно так не случается. Чаще всего такие подложные сертификаты -это дело рук сотрудника безопасности вашего офиса (ему же хочется читать, что вы делаете в интернете). Реже – хакерские атаки. В Китае и других странах с жёстким контролем за Интернетом вы также можете получать такие «подложные» сертификаты от провайдера, потому что по закону шифрование запрещено. Граждане этих стран принимают такие сертификаты, чтобы пользоваться Интернетом.
Хорошо, сертификат в порядке. А что за обмен ключами?
Дальше начинается магия чисел. В математике есть такие хитрые операции, которые проверяются быстро, а считаются долго. Например, если вдруг вы захотите найти два числа, на которые делится 91, придётся перебирать вообще все возможные варианты. Это долго. А если вы пойдёте в другую сторону – мы спросим, что получится, если умножить 13 на 7 – вы сразу поймёте, что это 91. Делая такие операции вместе с тем, с кем вы собираетесь установить шифрованное соединение, вы меняетесь ключами так, что любой «подслушивающий» вас получает только результаты, которые надо очень долго считать.
Ок, поменялись ключами, дальше всё шифруется?
Да. Но не спешите радоваться – абсолютной защиты это не даёт. Во-первых, вас всё равно слушает государство (либо ваше роднойродное, либо американское – это ведь, скорее всего, их центры сертификации). Во-вторых, сами сертификаты могут быть выпущены с уязвимостью (либо метод шифрования может быть уязвим), чтобы знающий человек мог их читать – тут вам передаёт пламенный привет Сноуден, который это спалил. В-третьих, несмотря на сложность подсчёта ключа, его всё же можно подобрать математически – правда, это займёт ни одну сотню лет, но если вдруг у организации, которая очень хочет вас послушать, есть невероятно большая вычислительная мощность, вас может ждать сюрприз. И, наконец, всё идёт к тому, что довольно скоро изменятся сами принципы вычисления таких чисел на процессорах (благодаря уже доступным в лабораториях квантовым компьютерам), поэтому через несколько лет, скорее всего, нас ждут большие изменения в самих методах шифрования. Проще говоря: сосед не узнает, провайдер не узнает, сисадмин не узнает, даже хакер, скорее всего не узнает, а вот КГБ бдит, товарищ.
А почему, если я переведу время на компьютере в 2050-й год, у меня не будет работать браузер из-за ошибок SSL?
Потому что вы тоже имеете сертификат и набор уже готовых ключей для ряда случаев. Операционная система или имеет много ключей (столько, чтобы хватило на много-много соединений на ближайшие 500 лет), или же умеет получать эти новые ключи с официальных серверов. Но ваш сертификат SSL – как и все сертификаты – имеет срок годности. Поэтому если вы скачком убежите далеко в будущее, он кончится, а новый сертификат будет взять неоткуда. Вот почему путешественников во времени с ноутбуками и телефонами ждут некоторые трудности. Но, хочется верить, это меньшее, с чем им придётся столкнуться в 2050 году.
Что ещё надо знать?
SSL-туннель не защитит вас от угроз на стороне сайта (ведь там всё расшифрруется, и администратор сайта увидит, что вы делаете – это же логично), и на вашей стороне, то есть на вашем компьютере. Это значит, что если вы поймали вирус – злоумышленник всё равно может видеть, что вы делаете независимо от шифрования. А ещё целая куча программ разбирает ваш шифрованный трафик – например, антивирус ищет там вирусы, а дорогая корпоративная система защиты от утечек – собственно утечки. В общем, если вы верите авторам антивируса, что они не читают вашу почту – всё в порядке.
То есть сам по себе SSL – это небезопасно?
Это достаточно безопасно, чтобы избежать большинства обычных угроз. Если за вами кто-то следит направленно, либо если вы не хотите уведомлять провайдера о своём любимом порно и том, с кем вы переписываетесь, надо выбирать ещё и другие методы защиты – например, VPN, одну из сетей даркнета и так далее. Там происходит не только шифрование, но и переадресация или перемешивание трафика, чтобы нельзя было понять, где и что происходит.
А что это значит – SSL?
Secure sockets layer - уровень защищённых cокетов, то есть, упрощая, «защищённое соединение». Разработан в 1996 году компанией Netscape. Компании уже давно нет, а протокол остался и лёг в основу современного Интернета.
Твитнуть
Плюсануть
Please enable JavaScript to view theВ последнее время только и говорят, что ssl сертификат влияет на выдачу, причем говорят об этом на каждом углу. Давайте в этой статье разберемся, зачем поисковые системы рекомендуют подключать ssl – сертификат для сайта, кому он нужен и каждый ли вебмастер обязан его установить.
Для начала установим, что же такое этот загадочный сертификат. Обратимся к определению: Secure Sockets Layer (или в народе SSL) – это протокол, который дает возможность установить полностью защищенное соединение между интернет – ресурсом и браузером. Это нужно для того, чтобы не дать сторонним образом вмешаться в соединение – перехватить данные, подделать или изменить. Происходит это за счет использования двух типов ключей приватного и публичного. Скрытый или приватный ключ хранится на сервере, а публичный предоставляется пользователю, который заходит на сайт со своего компьютера и своего браузера. Соответствие приватного и публичного ключа обеспечивает пользователю безопасность при использовании того интернет ресурса, на котором установлен данный сертификат.
Какие существуют виды ssl – сертификатов?
Существует три основных вида ssl – сертификатов:
1) Сертификат доверенного центра сертификации. Данный сертификат означает, что компания, которая использует сертификат предоставила центру сертификации свои полные данные – юр. адрес, контактные данные, инн, кпп, платежные реквизиты и прочие данные.
2) Сертификат недоверенного центра сертификации. Данный сертификат выдан неизвестным центром сертификации и ничего не гарантирует. Современные браузеры часто предупреждают пользователей, что на сайте установлен недоверенный сертификат и ресурс может красть и использовать в своих целях данные пользователя.
3) Самосозданный сертификат. Данный сертификат может сделать любой владелец ресурса и он просто сообщает владельцу, что мы такие – то, сами себе выписали сертификат. Данный сертификат как и недоверенный нигде особо не используется. Так как пользователя без его согласия браузер просто не пустит на сайт, использующий такой сертификат. Но, достаточно теории. Вернемся к основной проблеме, зачем нужен ssl сертификат.
SSL сертификат для сайта: как влияет на выдачу?
Разбираться в проблеме нужно с ее истоков. Для этого проанализируем новости авторитетных источников (чтобы не утруждать своих читателей я приведу лишь краткий вывод по анализу источников) и получим следующее. Шум о ssl сертификатах поднялся из – за того, что с начала 2014 года поисковая система Google полностью перешла на использование SSL сертификатов, поставив в приоритете безопасность пользователя. При этом Google вскользь упомянул, что наличие ssl сертификата на сайте будет благотворно влиять на ранжирование.
Сразу же возникает вопрос, это касается всех сайтов или только отдельных и специализированных. На основе анализа выдачи можно сказать, что такого вида сертификат необходим только для интернет – ресурсов, которые обязаны защищать соединение пользователя – это интернет магазины, платежные системы, банки и тому подобные сервисы. Если на ресурсе пользователь занимается приобретением товаров или услуг и производит оплату на том – же сайте, то сертификат такому сайту необходим. А для рядовых вебмастеров, которые занимаются информационными сайтами или содержат сайты, которые не предполагают оплату на самом ресурсе, такой сертификат не нужен. (Пример: Сайтам предпринимателей, которые занимается производством и реализацией срубов бань, запчастей и всех товаров, оплата которых не производится непосредственно на сайте, сертификат не нужен. При этом, если предприниматель занимается предоставлением банковских услуг, продает товары и принимает оплату прямо на своем сайте, то таким ресурсам сертификат необходим и Google будет учитывать наличие сертификата на таких сайтах).
Но, если вы не желаете подключать ssl сертификат, можно просто принимать оплату за услуги на специализированных сервисах, типа plati.ru, oplata.info и прочих, у которых есть подписанные ssl сертификаты.
При этом, возвращаясь к полезности ssl – сертификата нужно отметить одну важную деталь – сертификат гарантирует безопасность соединения, а пользователи больше предпочитают безопасные интернет – ресурсы, следовательно, каждая устойчивая компания должна получить ssl – сертификат.
Как получить SSL – сертификат?
Для этого нужно выполнить следующее:
1) Найти компанию, которая предоставляет возможность приобретения ssl сертификатов. Это может быть любой хостинг провайдер, например rackstore, их цены по ссылке http://rackstore.ru/ssl-sertificat.html или любая другая компания.
2) Заказать необходимый сертификат. Существует достаточное количество компаний – сертификаторов, описывать каждую нет смысла, так как у всех цели и потребности разные. Посмотрите виды сертификатов на специализированных форумах и выберите под ваши потребности.
3) Установить ssl – сертификат. Данную процедуру вы можете проделать как самостоятельно, так и воспользовавшись помощью хостинг – провайдера.
Таким образом подведем итоги статьи. Сертификат типа SSL необходим для малых и средних организаций, занимающихся деятельностью, предполагающей использование конфиденциальных данных клиента непосредственно в момент соединения клиента с интернет ресурсам. А также ssl сертификат – это вопрос имиджа, образа компании в сознании посетителя, как гарантирующей его полную безопасность.
В данном материале вы узнаете о том, как установить и настроить SSL-сертификат на Joomla и правильно перевести сайт на HTTPS-протокол. Рассмотрены возможные проблемы и приведены дополнительные действия, которые могут понадобиться при установке, а также после установки SSL на сайт.
Что такое SSL?
SSL (Secure Sockets Layer, пер. уровень защищенных сокетов) - это криптографический протокол, который используется, чтобы обеспечить зашифрованное соединение между сайтом и браузером. SSL сертификат позволяет нам использовать HTTPS.
Важно понимать, что по умолчанию все наши сайты загружаются по протоколу HTTP (Hyper Text Transfer Protocol, пер. протокол передачи гипертекста). При этом данные не шифруются и могут быть перехвачены и использоваться третьими лицами.
Вы можете сказать: «Мне нечего скрывать, пускай за мной следят». Но давайте рассмотрим подробнее ряд важных преимуществ, которые вы получаете при использовании SSL.
Преимущества использования SSL
1. Защита от перехвата
Если вы авторизуетесь на вашем сайте, используя публичный wi-fi (например, в кафе или метро), знайте, что в процессе соединения с вашим сайтом ваши данные могут быть перехвачены, а следовательно, вы можете потерять доступ к сайту (навсегда).
2. Защита клиентов
Первый пункт применим не только к вам как администратору, но и к клиентам. Другими словами у ваших клиентов могут украсть данные для авторизации с вашим сайтом. Поэтому все уважающие себя сайты используют защищенное соединение.
3. Высокие позиции в поисковой выдаче
Сайты, которые загружаются по https при прочих равных условиях получают более высокие позиции от поисковых систем.
4. Интеграции с сервисами
Для безопасности многие сервисы для интеграции с ними начинают требовать передачу данных по защищенному соединению. Следовательно, без наличия SSL сертификата вы не сможете работать с данными сервисами. Например, яндекс-касса, различные веб-пуш уведомления.
5. Визуальные характеристики.
У вашего сайта перед адресом появляется зеленый замочек, или название компании, что для знающих людей, говорит о защите данных, как следствие повышает доверие.
В скором будущем (2 - 3 года) протокол HTTP уйдет в небытие, как небезопасный протокол и будет только защищенное соединение.
Переходим к вопросу, как выбрать SSL-сертификат. С одной стороны, все просто купил сертификат и попросил хостинг-компанию установить сертификат на сайт. Но, есть ряд моментов. И первый - это выбор сертификата.
Виды SSL-сертификатов
SSL сертификаты выпускает ряд компаний (Comodo, Geotrust, Symantec, Thawte) и есть разные уровни сертификатов. Давайте разберемся какой же сертификат нам выбрать.
По уровню доверия сертификаты бывают:
Self-Signed (самоподписанные) - это сертификат, который вы можете сгенерировать самостоятельно. Браузеры не доверяют таким сертификатам, поэтому при входе на сайт выдается предупреждение о сомнительной безопасности. При взломе такого сертификата вам никто не будет возмещать ущерб. Кроме этого, в некоторых ситуациях, повлекших ущерб третьих лиц, к вам могут быть применены особые штрафные санкции.
Trusted (доверительные) - выдаются специальными центрами сертификации. Сертификат проверяется в браузере автоматически. В случае взлома сертификата ответственность ложится на на центр сертификации.
Количество доменов.
Стандартные SSL сертификаты - выпускаются для защиты одного доменного имени.
Wildcard SSL сертификаты - позволяют активировать защиту для одного домена и множества поддоменов.
Язык.
Стандартные SSL сертификаты - подходят для всех доменов с латинскими буквами. Не подходят для кириллических доменов.
IDN сертификаты - создаются специально для национальных доменов, в нашем случае кириллических.
Брэнд и усиленная защита.
EV (extended validation) сертификаты - сертификаты с расширенной проверкой компании (позвонят по телефону, проверят юридическую информацию). Данный сертификат отличается визуально от всех остальных. В строке браузера перед урл будет зеленая строка с названием вашей компании.
SGC сертификат - это самые мощные сертификаты из доступных на сегодня. Необходим для компаний среднего и крупного бизнеса, а так же если вы хотите хранить данные банковских карт клиентов на своем сайте.
Краткий итог по выбору сертификата.
- У вас обычный сайт и один домен - берем стандартный сертификат.
- Если у вас кириллический домен - берем IDN.
- Хотите защитить несколько поддонов - берем WildCard.
- Хотите зеленую строку - берем EV.
- Храните данные банковских карт клиентов на своем сайте - берем SGC.
Приобретение и установка SSL-сертификата
Рассмотрим общие ключевые особенности по приобретению и установке.
Покупка SSL-сертификата
Важные моменты по покупке:
- если вы покупаете стандартный сертификат, то он генерируется автоматически после оплаты и подтверждения вами доменного имени
- доменное имя подтверждается по почте: на E-mail отправляется автоматическое письмо со ссылкой для подтверждения
Для подтверждения требуется электронный адрес вида [email protected] или [email protected]
Никакие другие почтовые ящики вы указать не сможете, поэтому если у вас еще на домене не заведен один из указанных адресов, то создайте.
Установка SSL-сертификата
После оплаты на E-mail придут данные, которые нужно отправить хостинг-провайдеру, а именно:
- сертификат (начинается со слов begin sertificate ),
- приватный ключ
- цепочки сертификатов, если есть (не обязательно)
Всю установку сертификата к домену проделает хостинг компания.
Выделенный IP-адрес
Устанавливать SSL и переводить сайт на https можно как на прежнем IP-адресе, так и на выделенный (отдельный).
Т.е. можно остаться на прежнем IP-адресе, можно получить новый.
Преимущество нового IP-адреса в том, что он закреплен только за вашим доменом, как следствие у него по умолчанию хорошая карма и в случае с рассылками с сайта вероятно попасть в спам в ненужный момент сильно уменьшается.
Выделенный IP , как правило, платный: стоимость уточняйте у своего хостера.
После установки SSL-сертификата ваш сайт будет открываться как по протоколу http , так и по протоколу https . Протокол по умолчанию всегда http , если принудительно не назначен https .
Настройка SSL (https) для Joomla
Что значит нормальная работа по https?
Это когда сайт загружается корректно и у названия сайта горит зеленый значок (во всех браузерах кроме Safari , в этом браузере просто серый замок).
Если же на вашем сайте не все изображения загружаются по протоколу https или найдены другие, вышеперечисленные ошибки, то будет вот такой значок.
Нормальная работа сайта по https предполагает:
- соответствующий протокол для всех внутренних ссылок сайта
- https-протокол для CSS- и JS-файлов, картинок и иных подгружаемых файлов
- отправку данных форм по https
- редирект страниц с http на https
Поэтому сейчас переходим к настройке Joomla для соблюдения всех необходимых условий.
Изменения в файле конфигурации Joomla
- открываем файл configuration.php , находим директиву live_site и прописываем https://site.ru (URL без слэша на конце)
- в этом файле находим опцию force_ssl и ставим значение 2, чтобы админка и внешний интерфейс открывались по протоколу https (если поставим 1, то по защищенному протоколу будет открываться только админка)
Включение SSL в админке Joomla
Опцию force_ssl не обязательно изменять напрямую в файле конфигурации: можно зайти в панель управления Joomla (Система → Общие настройки , вкладка Сервер , раздел Настройки сервера ) и выбрать соответствующее значение для опции Включить SSL :
При этом измениться значение опции force_ssl в файле конфигурации Joomla .
Важно знать:
В настройках некоторых компонентов (VirtueMart, JoomShopping ) также есть опция по включению SSL для редиректа на https страниц данных компонентов.
При правильной настройке сервера и корректной установке SSL-сертификата опция Включить SSL (force_ssl в файле конфигурации) обеспечивает нормальную работу сайта на Joomla по https : все подключаемые файлы и внутренние ссылки будут работать по защищенному протоколу, а при запросе страниц по протоколу http будет происходить редирект на https .
Дополнительные действия для Joomla
Если приведенные выше действия не обеспечили нормальную работу Joomla по протоколу https , то опробуйте следующие методы:
Изменение в файле.htaccess
В конец файла .htaccess добавляем следующую строку кода:
SetEnvIf X-SSL-Emu on HTTPS=on
Изменение в файле конфигурации
Добавляем в конец файла configuration.php следующую строчку:
$_SERVER["HTTPS"] = "on";
Получится вот так:
Этот хак должен обеспечить работу сайта по https , но содержимое файла будет обновляться при каждом изменении конфигурации, и указанную выше строчку придется дописывать вновь.
Редирект главной страницы
Открываем файл .htaccess и прописываем следующий код для главного редиректа при запросе вашего сайта через строку браузера.
Код размещаем после строки RewriteEngine On :
RewriteCond %{HTTPS} off
RewriteRule ^(abc/def|ghi)(.*)/?$ https://%{HTTP_HOST}%{REQUEST_URI}
Сейчас ваш сайт всегда будет открываться по протоколу https и будет загружаться со всеми стилями, скриптами и изображениями.
Но! Осталось проделать еще 2 важных пункта.
Пути к изображениям и формам
Если на странице вашего сайта будут найдены изображения, которые загружаются не по протоколу https , то зеленого значка около названия вашего сайта не видать. Сам сертификат при нажатии на него будет говорить, что не все элементы грузятся по безопасному протоколу. В этом случае проверяем и исправляем.
По умолчанию, все картинки, которые вы вставляете через формы вставок картинок или через визуальный редактор автоматически меняют свой протокол загрузки и за них переживать не стоит.
Но есть изображения, путь которые вставлены в HTML-код и к ним указан абсолютный путь. Вот у таких изображений нужно в пути вместо http:// написать https:// .
Изображения могут быть как в текстах, модулях, так и неправильно прописаны, например, в файлах стилях вашего шаблона.
На будущее, если вы хотите указать абсолютный путь (полный) к файлу, то прописываем без указания протокола, например //site.ru/images/photo.jpg
Если на вашем сайте есть формы на подписку, то в коде формы меняем URL , на который будут передаваться данные.
В результате нам нужно проверить все страницы сайта и, при необходимости дописать букву у обозначения протокола.
Как искать изображения, которые загружаются не по https?
Важно знать:
Если часть страниц вашего сайта будет загружаться правильно, а часть неправильно, то у вас возникнут проблемы с авторизацией: авторизовавшись на правильной странице и перейдя на неправильную, авторизация сбрасывается и наоборот. В определенных случаях вы не сможете добавлять материалы.
Действия после настройки SSL на Joomla
После того, как будет обеспечена нормальная работа страниц сайта по протоколу Https , необходимо осуществить следующие действия:
Сообщить поисковым системам, что сайт переехал на https
Это важный момент в отношении SEO : для поисковых систем сайт, доступный по разным протоколам, будет считаться разными сайтами, что может создать проблемы для продвижения сайта. Чтобы исключить такие проблемы, необходимо воспользоваться соответствующими инструментами поисковых систем:
Заходим в Яндекс.Вебмастер , ставим соответствующую галочку:
Заходим в robots.txt и дописываем директиву host: https://site.ru
В Google Search Console необходимо будет добавить новый сайт с протоколом https , предварительно подтвердив права на него предложенными сервисом способами.
Проверка карты сайта
Обязательно следует проверить карту сайта на то, что все ссылки начинаются c протокола https .
Проверка старых редиректов
Если вы делали редиректы через Redj или RSSEO , то проверьте и подправьте, чтобы конечный адрес был с https .
Другие материалы по безопасности Joomla
Дополнительная защита админки Joomla 3
Восстановление пароля администратора в Joomla 3
SSL-сертификат (https-протокол) Joomla
Akeeba Backup : резервное копирование сайта Joomla
Права на файлы и папки в Joomla 3.x
SSL (англ. Secure Sockets Layer - уровень защищённых сокетов) - криптографический протокол. Предназначен для шифрования данных при обмене информацией между сетевыми устройствами. SSL изначально разработан компанией Netscape Communications для добавления протокола HTTPS в свой веб-браузер Netscape Navigator. Впоследствии, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.
Больше материалов доступно в статье на википедии . Не буду вдаваться во все подробности, но опишу как можно проще его применение по отношению к вэб-сайтам.
Итак, частое использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. HTTPS по умолчанию использует TCP-порт 443.
Рассматривая ssl соединение нужно понимать что такое приватный или серверный ключ или server private key, запрос подписи сертификата или CSR (Certificate Signing request), публичный ключ (public key), сертификат безопасности или Security Certificate, шифр, cipher или алгоритм шифрования, центр сертификации или Certification Authority.
Приватный или серверный ключ - начало жизни любого сертфиката. Это текстовый файл который содержит в себе набор непонятных символов, напоминающих абракадабру. Эта абракадабра является ключем на основе которого происходит шифрование исходящих и дешифровка входящих данных на стороне сервера. На основе этого файла-ключа генерируется запрос подписи сертификата или CSR (Certificate Signing request).
Запрос подписи сертификата или CSR - такая же закодированая абракадабра как и ключ. Эта абракадабра генерируется на основе серверного ключа и содержит информацию которая будет включена в сертификат. Это информация о вашей организации (organization name), имя вэб сайта, на котором будет установлен сертификат (common name), структурное подразделение организации (organizational unit), место нахождения или город (locality) и страна (country). Все эти вопросы задаются генератором на этапе создания запроса. Также он содержит публичный ключь (public key) который тоже будет включен в сертификат.
Центр сертификации или Certification Authority - сторона (отдел, организация), чья честность неоспорима, а открытый ключ широко известен. Задача центра сертификации - подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи. Другими словами - это контора которой доверяют все производители браузеров. Именно туда направляется CSR для того что бы ваш сайт проверили на подлинность, принадлежность Вам и за определенные деньги на основе своего ключа и Вашего CSRа сделали Вам сертификат безопасности.
Сертификат безопасности - опять же абракадабра потому что зашифрованный файл, который содержит информацию о Вашей организации, вэб-сайте и все то, что было указано на этапе генерации CSR. Также подлинный сертификат безопасности содержит подпись Центра сертификации о том, что его проверили и подтвердили, что вы - это вы, ваш вэб-сайт - тот за кого себя выдает и с ним можно дружить. Если такой сертификат прикручен к сайту, по при обращении к нему по протоколу https начало адресной строки превратится в приятную зеленку и браузер будет считать такое соединение безопасным и очень положительным во всех отношениях.
Отдельно нужно упомянуть самоподписанный сертификат - это такой же сертификат безопасности, как и предыдущий с одним важным минусом: в нем не содержится цифровой подписи центра сертификации. Обычно при обращении к таким сайтам экран становится красным и браузер настойчиво рекомендует отказаться от установления защищенного соединения с сервером.
Что же происходит, когда мы делаем обращение к серверу использую https вместо http?
SSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия или HandShake. Во время рукопожатия клиент и сервер договариваются о том как они будут обеспечивать безопасную передачу данных:
1. Клиент посылает серверу номер версии SSL клиента, зашифрованные параметры чтобы общаться с клиентом, используя SSL.
2. Сервер делает то же самое. Сервер также посылает свой сертификат, который требует проверки подлинности клиента. После идентификации сервер запрашивает сертификат клиента.
3. Клиент использует информацию, переданную сервером для проверки подлинности. Если сервер не может быть проверен, пользователь получает предупреждение о проблеме и о том, что шифрование и аутентификация соединения не может быть установлена. Если сервер успешно прошел проверку, то клиент переходит к следующему шагу.
4. Используя все данные, полученные до сих пор от процедуры рукопожатия, клиент (в сотрудничестве с сервером) создает предварительный секрет сессии, в зависимости от используемого шифра от сервера, шифрует его с помощью открытого ключа сервера (полученного из сертификата сервера, отправленного на 2-м шаге), а затем отправляет его на сервер.
5. Сервер пытается аутентифицировать клиента. Если клиент не может пройти проверку подлинности, сеанс заканчивается. Если клиент может быть успешно аутентифицирован, сервер использует свой закрытый ключ для расшифровки предварительного секрета, а затем создается главный секрет на сервере и на клиенте.
6. И клиент, и сервер используют секрет для генерации ключей сеансов, которые являются симметричными ключами, использующимися для шифрования и расшифрования информации, которой обмениваются во время SSL сессии.
7. Клиент посылает сообщение серверу, информируя его, что будущие сообщения от клиента будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.
8. И в заключение, сервер посылает сообщение клиенту, информируя его, что будущие сообщения от сервера будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.
На этом рукопожатие завершается, и начинается защищенное соединение, которое зашифровывается и расшифровывается с помощью ключевых данных.
К плюсам использования защищенных ssl соединений можно отнести:
- уверенность в том что данные передаются в защищенном виде. В случае перехвата отправленного пакета злоумышленник не сможет его открыть/почитать/изменить, так как он не имеет ключа шифрования, который является уникальным для каждой сессии.
- красивая адресная строка в браузере.
- доказательство всем на сколько крутой твой вэб-сайт.
Ясное дело, что главным преимуществом является первый пункт.
Есть и вторая сторона медали. К недостаткам использования ssl можно отнести:
- деньги. Да за сертификаты нужно платить конторам, которые называются центрами сертификации. Очень уважаемые центры сертификации берут очень неплохие деньги за то, что подписывают Ваш сертификат.
- опять деньги? Да. Https соединения более прожорливы в плане ресурсов системы. Может потребоваться более мощный сервер. Именно поэтому не рекомендуется использовать https для всего вэб сайта.
(Visited 455 times, 1 visits today)
TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.
Что такое SSL и что такое TLS?
SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.
Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:
SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года
Принцип работы SSL и TLS
Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:
Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.
Установка соединения обеспечивается в несколько этапов:
1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.
2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать
3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.
4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.
5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.
6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.
Корневой сертификат
Чуть выше я упомянул корневой сертификат. Это сертификат авторизационного центра, подпись которым подтверждает, что сертификат, который подписан, является именно тем, который принадлежит соответствующему сервису. В самом сертификате обычно содержится ряд информационных полей, в которых содержится информация об имени сервера, которому выдан сертификат, и сроках действия этого сертификата. Если срок действия сертификата истек, он признается недействительным.
Запрос на подпись (CSR, Certificate Sign Request)
Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.
Клиентский сертификат
Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.
Цепочка действий по генерации сертификатов
Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.
Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.
$ openssl genrsa -out root.key 2048 Generating RSA private key, 2048 bit long modulus ..........+++ ...........................................+++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ".", the field will be left blank. ----- Country Name (2 letter code) :RU State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) :IT Service Common Name (e.g. server FQDN or YOUR name) :My Company Root Certificate Email Address :[email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password : An optional company name :My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] Getting Private key
Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.
Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.
Просмотр информации о сертификате
Содержимое сертификата можно просмотреть таким образом:
$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] notAfter=Jan 22 11:49:41 2025 GMT
Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.
Серверный сертификат
Для подписи сертификата для сервера нам нужно выполнить следующие действия:
1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно
В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата
$ openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus ...................................................................................+++ ..........................+++ e is 65537 (0x10001) $ openssl req -new -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ".", the field will be left blank. ----- Country Name (2 letter code) :RU State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) :IT Service Common Name (e.g. server FQDN or YOUR name) :www.mycompany.com Email Address :[email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password : An optional company name : $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] notAfter=Jan 25 12:22:32 2016 GMT
Таким образом сертификат сервера подписан и мы будем знать, какой организацией выдан этот сертификат. После подписи готовый сертификат можно использовать по назначению, например, установить на веб-сервер.
Установка SSL/TLS-сертификата на сервер с nginx
Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:
1) Скопировать файлы.key и.pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private
2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):
Server { listen 443; server_name www.mycompany.com; root html; index index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # Не рекомендуется использовать SSLv3 !!! # Он здесь только для примера ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; location / { try_files $uri $uri/ =404; } }
3) Перезапустить nginx
4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.
Установка SSL/TLS-сертификата на сервер с Apache
Установка SSL/TLS-сертификата на Apache выглядит примерно так же.
1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории
2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен
3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:
При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:
Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку
NameVirtualHost *:443
Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf
4) Перезапустить веб-сервер Apache
Создание клиентского сертификата
Клиентский сертификат создается примерно так же, как серверный.
$ openssl genrsa -out client.key 2048 Generating RSA private key, 2048 bit long modulus ........................+++ ..................................................+++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ".", the field will be left blank. ----- Country Name (2 letter code) :RU State or Province Name (full name) :Saint-Petersburg Locality Name (eg, city) :^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ".", the field will be left blank. ----- Country Name (2 letter code) :RU State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petrersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) :Engineering Common Name (e.g. server FQDN or YOUR name) :Ivan Ivanov Email Address :[email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password : An optional company name : $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] notAfter=Jan 25 13:17:15 2016 GMT
Если необходим клиентский сертификат в формате PKCS12, создаем его:
$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Enter Export Password: Verifying - Enter Export Password:
Теперь можно использовать клиентский сертификат для работы с нашим сервером.
Настройка nginx на использование клиентских сертификатов
Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:
# Корневой сертификат(ы), которым(и) подписан клиентский ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Возможные варианты: on | off | optional | optional_no_ca ssl_verify_client optional; # Глубина проверки цепочки сертификатов, которыми подписан клиентский ssl_verify_depth 2;
После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.
Настройка Apache на использование клиентских сертификатов
Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:
# Директория, содержащая корневые сертификаты для проверки клиентов SSLCARevocationPath /etc/apache2/ssl.crl/ # или файл, содержащий сертификаты SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Опция верификации клиента. Возможные варианты: # none, optional, require and optional_no_ca SSLVerifyClient require # Глубина просмотра цепочки подписей. По умолчанию 1 SSLVerifyDepth 2
Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.
«Прослушка» информации о сертификате при помощи openssl
Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.
На стороне сервера запускаем прослушку порта при помощи openssl:
Openssl s_server -accept 443 -cert server.pem -key server.key -state
На стороне клиента обращаемся к серверу, например, culr’ом:
Curl -k https://127.0.0.1:443
В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.
Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:
Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3
Со стороны сервера ошибка выглядит так:
140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:
Со стороны клиента так:
Curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):
Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key
Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.
Безопасность
При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.
В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.
Запись опубликована автором в рубрике с метками , .Навигация по записям
: 29 комментариев
cl-service.com
CSR клиент генерирует сам при заказе сертификата, где сохранять закрытый ключ также решает клиент, для выпуска сертификата нам не нужен закрытый ключ и клиент нам его никак не передает. Естественно если это происходит на обычном виртуальном, то у администраторов с root доступом к серверу есть доступ и к ключам, которые там хранятся.
- Доброжелатель.
Тема сисек не раскрыта, ибо описанная технология работы PKI не имеет ничего общего с заголовком темы. Хоть бы для причия ссылки на rfc привел.
P.S. Был такой анекдот про собаку и блоху. - Доброжелатель.
Нивкоем случае не хотел тебя обидеть. Искал инфу о различии SSl и TLS на практике и твоя ссылка в гугле была первая. Был заинтрегован названием темы. Все круто, так держать!
- DrAibolit
Благодарю за толковые пояснения о цифровой сертификации. Я новичок в этом=)
Надеюсь разъясните следующий вопрос.
Поскольку в интернет индустрии очень развита тема мошенничества, хотелось бы научиться определять на «вшивость» самостоятельно посещаемые мною сайты (особенно, где присутствуют кашельки и оплаты, инвестиции и т.д) и определять исходя из этого степень моего доверия (приходится часто регистрироваться, оставлять личную информацию, совершать покупки, транзакции, инвестиции). Если я правильно понял, что наличие данной сертификации позволяет сделать такую оценку. Ну и с другой стороны, получить ее не проблема и даже бесплатно.
Как или с помощью какой программы можно определить наличие цифрового сертификата у того или иного сайта? и желательно его категорию, которая присваивается при выдаче спецорганом SSL DV (выдача сертификата проводится с проверкой только домена), SSL OV (с проверкой организации), EV (с расширенной проверкой юрлица). Мошеннические сайты скорее всего последним вариантом сертификации пользоваться не станут..
Буду рад, если поведаете еще способы определения надежности сайтов))- mnorin
Автор записи
Какой-то определенной программы для этих целей я еще не встречал, но пару советов по этому поводу могу дать.
Можно использовать, например, Chromium или Google Chrome. Возьмем, например, сайт https://www.thawte.com/ — компания, которая собственно цифровымисертификатами и занимается.
В адресной строке будет написано название компании и зеленый замочек. Это значит, что организация проверена, это как минимум SSL OV.
Если кликнуть на замочек, а в выпавшем окошке «Details», а затем «View Certificate», то можно увидеть информацию о сертификате. Для Thawte сертификат подписан следующим сертификатом: «thawte Extended Validation SHA256 SSL CA», а сертификат для click.alfabank.ru тоже подписан Thawte, но другим сертификатом. Это «thawte EV SSL CA — G3», то есть они тоже проходили Extended Validation.
Как-то так.
- mnorin
Автор записи
- Руслан
Раздел «Принцип работы SSL и TLS», «Клиент генерирует случайную цифровую последовательность».
Я был уверен что клиент генерирует сеансовый закрытый и, соответственно, открытый ключи (который вы, очевидно, и назвали «цифровая последовательность»). Открытый ключ передаётся серверу и сервер шифрует пакеты в сторону клиента сеансовым открытым клиентским ключом.
Уточните, пожалуйста.
- Новичок
Статья очень полезная! Даже есть практические примеры=) Только я не понял одну вещь — в чем различие между корневым сертификатом и серверным? или это одно и тоже?
- Виталий
Здравствуйте.
Хостер предложил услугу - SSL для виртуальных серверов. Воспользовались. Оказалось, что для третьего уровня, т.е. http://www.site.ru сертификат недействителен, только для site.ru. Притом, посетителей упорно кидает на протокол https, не важно, заходят они на site.ru или на http://www.site.ru . Разумеется, во втором случае браузер начинает истошно ругаться, а посетитель до сайта так и не добирается.
А для тех, кто до сайта таки добрался, сайт стал выглядеть криво, пропала часть меню, перестала отображаться часть картинок в выдаче некоторыми компонентами.
- Как приготовить классические вареники с творогом
- Как сделать тесто для яблочной шарлотки Как приготовить шарлотку с яблоками песочное тесто
- Отечественной войны 2 степени
- День полного освобождения Ленинграда от фашистской блокады
- Манная каша на молоке: пропорции и рецепты приготовления Манная каша 1 порция
- Суп-пюре из брокколи с сыром Рецепт крем супа из брокколи с сыром
- Гороскоп: характеристика Девы, рождённой в год Петуха