Ssl что это такое. Принципы шифрования сертификатом

Перед тем как приступить к разбору темы - маленькое отступление: в январе 2017 года сайт перешел на безопасный протокол https (и вам советует). Также предлагаем и вам помощь в переезде на безопасный протокол . Зачем? Как это сделать? И какой период лучше всего выбрать? Вот об этом сейчас и расскажем.

В статье пойдет речь о переезде сайтов на безопасный протокол HyperText Transfer Protocol Secure (https) . Тема на сегодняшний день считается «заезженной» и рассмотрена на многих ресурсах, но от этого она не становится менее актуальной. Читатели нашего блога и постоянные клиенты часто интересуются - как переехать на https? Зачем мне переходить на https? Нужен ли https для моего сайта? Чтобы ответить на все вопросы разом и помочь тем, кто все еще не разобрался в вопросе, мы и написали эту статью.

Для начала давайте разберемся, что такое https? HyperText Transfer Protocol Secure - это безопасный расширенный протокол http с ключом шифрования для передачи данных или гипертекста (термин «гипертекст» был введен в 1965 американский социологом, философом и первооткрывателем в области информационных технологий Нельсоном, Теодором Холмом), примером гипертекста являются веб-страницы - документы HTML.

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные механизмы SSL и TLS.

Что такое SSL и TLS

SSL - (secure sockets layer - уровень защищённых сокетов) - набор правил с более безопасной связью, регламентирующих применение шифровальных (криптографических) преобразований и алгоритмов в информационных процессах.

TLS - (Transport Layer Security - безопасность транспортного уровня) - протокол, основанный на спецификации протокола SSL версии 3.0. Хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.

С терминологией более менее разобрались, теперь переходим к тому, как заставить наш сайт работать на https.

Для того, чтобы заставить наш веб-сервер принимать и обрабатывать https-соединение, необходимо установить в систему SSL сертификат.

SSL сертификат - уникальная цифровая подпись вашего сайта, основанная на двух типах криптографических ключей - приват и паблик.

Публичный ключ не является секретным и он присутствует в запросе.

Приватный ключ располагается на вашем сервере и должен быть известен только вам.

Помимо паблик ключа, в сертификате содержатся также и другие сведения: версия, серийный номер, время действия сертификата, издатель и другие данные.

В частности, время действия сертификата очень важно. Браузеры не будут считать ключ валидным, если время действия ключа еще не наступило или (что случается чаще) уже закончилось.

Более подробную информацию об уже установленном на сайте сертификате вы можете посмотреть с помощью специальных сервисов, таких как:

https://www.ssllabs.com/ssltest/index.html - он передоставит расширенную техническую информацию о сертификате.

https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp - проверит, насколько верно установлен сертификат.

Типы SSL сертификатов по валидации

Что такое SSL сертификат и зачем он нужен вроде разобрались).

Теперь давайте разберем их типы по валидации:

Самоподписанный сертификат. Оговорюсь сразу, данный вид сертификата НЕ подойдет 99% пользователям. Плюс у данного сертификата один - цена (он совершенно бесплатен). Самый весомый минус - при переходе на ваш сайт из поисковой системы или по любому другому заходу пользователю будут показаны вот такие сообщения:

Цена: 0 руб.

Валидация по домену (Domain Validated) - SSL-сертификат, при оформлении которого производится только проверка доменного имени. Также данные сертификаты называют сертификатами начального уровня доверия. Подойдут практически 90% владельцев сайтов. Являются самыми распространенными. Подходят как физическим, так и юридическим лицам. Выдача данного сертификата, как правило, производится в течение суток.

Вид в адресной строке:

Цена: может колебаться от 800 руб./год до 3000 руб./год (хотя эта цифра не предел).

Валидация организации (Organization Validation) - сертификат с повышенной надежностью. При выдаче сертификата производится проверка компании, проверяется не только право владения доменом и принадлежность веб-сайта организации, но и существование компании как таковой. Доступен только юридическим лицам. При выдаче данного сертификата могут быть запрошены следующие документы: свидетельство ИНН/КПП, свидетельство ОГРН, свидетельство о регистрации доменного имени, и.т.д.

Вид в адресной строке:

Цена: может колебаться от 2000 руб./год до 35000 руб./год .

Расширенная валидация (Extended Validation) - сертификат с самым высоким уровнем аутентификации между всеми типами SSL сертификатов. Не подойдет 99% «смертных» из-за своей цены и способа проверки. Предназначен для крупных корпораций. Доступен только юридическим лицам. Зеленая адресная строка браузера отображает название компании и обеспечивает визуальное подтверждение безопасности вашего сайта.

Вид в адресной строке:



Цена: может колебаться от 12000 руб./год до 150000 руб./год .

Еще существует отдельный вид сертификатов, о котором нельзя не сказать - это сертификаты Wildcard . Данный вид сертификата стоит выбрать, если у вас структура сайта представлена в виде поддоменов. Или требуется защита передаваемой информации на субдоменах. На некоторых хостингах данный вид представлен в виде опции.

Цена: может колебаться от 1500 руб./год до 35000 руб./год .

Также для реализации https соединения на некоторых хостингах требуется оплата выделенного IP, цена которого может быть равна
1200 руб./год .

Если у вас возникнут проблемы с установкой или выбором SSL сертификата, вы всегда можете обратиться к своей хостинг-компании или к нам (цена рассчитывается индивидуально).

Теперь давай разберем, для чего вы прочитали 5716 байт предыдущего текста, и ответим на вопрос - для чего нам нужно переходить на https.

Для чего нужно переходить на https?

Причин несколько и все весомые:

Подходим к завершающей части и ответу на вопрос - как корректно переехать на https с минимальными потерями.

Инструкция по переезду на https

Вот вроде и все. Если сомневаетесь, что справитесь своими силами, обращайтесь к нам . Посмотрим ваш сайт, сориентируем по стоимости и поможем с переездом.

При подготовке материала мы ориентировались на официальные источники Яндекса и Google. Однако, отмечу, что 20 марта 2017 г. в блоге Яндекса была опубликована новая информация по переезду на HTTPS . В связи с этим многим может показаться, будто Яндекс сообщает, о том, что нет необходимости соблюдать пункт №7 данной статьи. В материалах Яндекса это вопрос №4.

Однако обращаем ваше внимание, что в комментариях к этому же материалу Елена Першина (сотрудник компании Яндекс) отвечает Бакалову Игорю: «Редирект лучше настраивать, когда большая часть страниц http-версии будет исключена из поиска», что соответствует рекомендациям из пункту №7 настоящей статьи.

Некоторые сайты отображают пиктограмму замка возле адреса. Его цвет может быть зеленый, золотой, серый. Иногда такого замка нет или он перечеркнут. В некоторых случаях можно увидеть строку зеленого цвета возле адреса с названием сайта. Наличие замка или такой строки указывает на то, что сайт имеет установленный SSL сертификат, и данные передаются по протоколу с защитой.

SSL сертификат что это простыми словами

SSL – криптографический протокол для безопасной связи, используемой за счет аутентификации ключей обмена с симметричным шифрованием. Это и позволяет оставаться сообщениям скрытыми. Изначально он был разработан для того, чтобы добавить протокол HTTPS в веб-браузер.

Шпионские директивы часто пытаются отвлечь врага и не дать ему прочесть сообщение, которое будет отправлено в другую страну. Поэтому существует специальный шифр, которым пользуются в такой ситуации. Можно рассмотреть на примере произведения Стругацких «Пикник на обочине». Для начала следует поразмыслить над написанием обычного письма, после чего каждое слове заменяется соответствующую цифру.

Тогда 137 будет означать, что расположение слова приходится на первую страницу, третью строку и седьмое слово. Если получателю отправить «137-536-9978», то придется взять книгу Стругацких и начать расшифровывать, но в обратной последовательности. Если есть вероятность перехвата такого письма, то никто не сможет понять, что там написано. Это потому, что перехватчик не в курсе, какую книгу мы берем за основу шифрования.

Принцип работы SSL аналогичен. При написании и отправке сообщения применяется каждый раз такая новая книга. Поэтому очень сложно взломать и прочитать зашифрованное письмо. Поэтому данное шифрование по праву может считаться безопасным.

А что такое SSL сертификат, и что с ним делать – это мы обсудим ниже.

Значение SSL сертификатов

Многие не знают, зачем нужен SSL сертификат сайту. Его наличие принесет огромную выгоду: сохраняя под защитойвводимые личные данные:

• пароль и логин для входа в аккаунт;
• номер карты банка;
• адрес электронной почты;
• контактный телефон.

Его установка будет важна для сайтов крупных компаний, финансовых организаций, систем для проведения платежей, интернет-магазинов, соцсетей, государственных организаций и так далее.

Что дает SSL сертификат? Владельцы различных сайтов заинтересованы в его установке. Это не только повышает уровень безопасности, но и значительно улучшает репутацию сайта. Ведь меры, которые помогают обезопасить личные данные от мошенников, – это лучшая забота о своих пользователях. При наличии SSL протокола нет повода для беспокойства сохранности конфиденциальности. Взломать шифр нереально, так как используется.

Основное назначение SSL сертификата – это гарантировать полную анонимность и зашифрованность переданного сообщения. Благодаря аутентификации ключами и анонимному обмену, способ шифрования является безопасным.

Разобравшись для чего необходим SSL сертификат, поговорим о его видах и особенностях.

Разновидность

Такие сертификаты имеют разную стоимость, что определяет их уровень престижности. Ценообразование зависит от сложности проверки и технических возможностей. Так что выбирая его для установки, определитесь с объемом и направленностью проекта.

Зеленую строку лучше выбирать организациям коммерческого типа.

Для сайта с личным блогом можно выбрать более простую версию. Также может быть защищена лишь одна страница или несколько порталов одновременно.

Разновидности сертификатов

Для физических лиц, имеющих личный проект, блог или форум, оптимальным станет установка SSL сертификата для домена (проверяет доменное имя).

Особенно это подойдет владельцам порталов, на которых пользователи регистрируют свои аккаунты, делают подписки на электронную рассылку, производят оплату курсов или услуг. Для того чтобы его выпустить, не понадобиться документальное подтверждение. Средний строк получения составляет около 15 минут.

Для бизнеса (малый и средний), что развивает корпоративный сайт, интернет-магазин агентство лучше его использовать с организационной проверкой. Это важно, если происходит хранение личных данных, переписки между пользователями, производится покупка товаров или оплата услуг.

Получить такой SSL сертификат для сайта можно после проверки сертификационным центром прав на домен и регистрацию организации. Срок проверки занимает 1-3 дня.

Для большого бизнеса – государственная организация, банки, крупные магазины и центры требуются дополнительные проверки. Особенно, если происходит хранение ценных документов, крупных денег и данные платежных систем. Расширенная проверка занимает около 2 недель.

Несколько доменов. Установка мультидоменного типа нужна для почтовых серверов, холдингов, торговых сетей. Пользуясь одним SSL сертификатом, можно защищать до 100 доменов одновременно.

Что будет если не продлить SSL сертификат? Влияет ли эта ошибка на поведение ваших пользователей?

Что видят пользователи при входе на ресурс, на котором срок действия сертификата безопасности сайта истек?

Они получают довольно пугающее предупреждение:

Вы бы продолжили, если бы увидели такое сообщение при попытке входа?

Но исследование SEO-компании "Hallam Internet", показало, что посещения на сайт почти не изменились и показатели отказов, что логично, тоже.

Но не стоит затягивать с обновлением SSL сертификата, так как, если в течение суток изменения небольшие, то в случае недель и месяцев, могут появиться проблемы с ранжированием.

Выбор зависит от вас. Главное помнить, что установка SSL сертификата на сайт поможет сохранить безопасность каждого клиента.

Это такой режим соединения с сайтом, когда вся информация шифруется. То есть, например, если вы вводите данные своей банковской карты, то их видите только вы и сайт, который их получает.

Погодите, а обычно разве не так?

Обычное интернет-соединенение проходит примерно через 15 узлов. Например, когда вы покупаете что-то в интернет-магазине, сидя у себя в офисе, отправляемая и получаемая вами информация проходит сразу через несколько узлов:

• Через локальную сеть или Wi-Fi – её может увидеть администратор сети и ваши коллеги.
• Через ближайший узел провайдера – там её могут увидеть сотрудники провайдера, и там же она может сохраниться для госорганов.
• Через региональный маршрутизатор (точнее, несколько) - ещё несколько инженеров.
• И в обратном порядке до сервера, где работает магазин – его узел провайдера, его локальная сеть.

Кроме того, к этой цепочке может подключиться злоумышленник, который будет специально вас слушать. В лучшем случае это будет ваш сосед, который «прослушивает» открытый Wi-Fi.

То есть когда я использую SSL, никто из этих людей не видит, что я передаю и получаю?

Да. Точнее, «снаружи» тогда будет видно только адрес сайта, с которым вы работаете. Вся информация пойдёт в шифрованном туннеле.

Как понять, соединён ли я по SSL?

Самый простой способ, если вы работаете с сайтом, - посмотреть строку адреса.

Если в начале его адреса будет написано https, а не http, то всё в порядке. Эта буква «s» в конце означает «secure», то есть защищённый, шифрованный. Современные браузеры покажут замок около адреса – наверняка вы уже видели такую иконку не раз. Кроме того, большая часть современных браузеров предупреждает о том, что вы передаёте важные данные по открытому каналу. Предполагается, что в будущем большинство сайтов будут работать по SSL полностью. Сейчас же это, в основном, касается только тех страничек, где происходит оплата.

Если я покупаю что-то в интернет-магазине, а сайт без https, это плохо?

Сегодня большая часть интернет-магазинов переходит на шифрованный SSL-канал только для ввода платёжных данных. Более того, для ввода данных банковской карты, например, вас чаще всего перебрасывает на SSL-страницу платёжной системы – чтобы даже владелец сайта магазина не увидел данных, только банк. Поэтому стоит обращать внимание на шифрование при оплате.

По SSL можно соединяться только с сайтом или с чем-то ещё?

Этот протокол обмена информацией используют многие мессенджеры, например, Вотсап, Вайбер, ICQ (в последних версиях), Телеграм, Фейсбук Мессенджер и так далее. И многие приложения тоже, например, банковские. Кроме того, по SSL можно соединяться с чем угодно – это просто способ обмена ключами и ширования, то есть средство построения связи.

Что такое SSL-сертификат?

Когда вы соединяетесь с новым сайтом, и начинаете шифрованный обмен, происходит две вещи:

1. Вы проверяете его сертификат
2. И меняетесть ключами.

Сертификат в самом простом случае – это удостоверение, что тот сайт – именно тот сайт. То есть, грубо говоря, его «паспорт». Этот «паспорт» подтверждается «нотариусом» интернета – сертификационным центром. Иногда, конечно, сертификационные центры взламывают, и шифрованные данные становятся известны хакерам, но в целом таким центрам можно доверять. На этом доверии держится весь Интернет.

Что за проверка сертификата?

Ваш браузер в начале процедуры установки шифрования смотрит в «бумаги» сайта и проверят его «паспорт». Если там всё в порядке, то вы на современном браузере даже ничего не заметите, и просто перейдёте к следующему этапу. Если же что-то не так – например, сертификат вчера кончился, или он подписан самим сайтом (без независимой стороны) или что-то ещё подозрительно – вы увидите предупреждение.

Почему?

Потому что если сертификат неверно подписан, просрочен или подписан не тем сертификационным центром, который должен там быть - скорее всего, это подложный сертификат, который кто-то заставляет вас подписать вместо настоящего. Конечно, в реальном мире паспорт тоже мог искупаться в реке, потом по нему мог побегать кот, и наконец, на нём мог пририсовать усы к фотографии ребёнок, но обычно так не случается. Чаще всего такие подложные сертификаты -это дело рук сотрудника безопасности вашего офиса (ему же хочется читать, что вы делаете в интернете). Реже – хакерские атаки. В Китае и других странах с жёстким контролем за Интернетом вы также можете получать такие «подложные» сертификаты от провайдера, потому что по закону шифрование запрещено. Граждане этих стран принимают такие сертификаты, чтобы пользоваться Интернетом.

Хорошо, сертификат в порядке. А что за обмен ключами?

Дальше начинается магия чисел. В математике есть такие хитрые операции, которые проверяются быстро, а считаются долго. Например, если вдруг вы захотите найти два числа, на которые делится 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 сертификат, и почему мне так срочно нужно переносить свой сайт с http на https. Но все вокруг твердили, что переезжать надо обязательно, иначе – каюк.

Тогда я решил самостоятельно разобраться, что же это такое, и зачем оно нужно. Результаты моих исследований вы найдете ниже.

И знаете что? SSL сертификаты – это одна из главных веб-мистификаций последних лет. И вполне серьезная угроза для всех интернет-пользователей.

Что такое SSL сертификат самыми простыми словами

Вспомните, как часто происходит дело в шпионских детективах. Нам нужно отправить послание сообщнику в другую страну, и нам очень не хочется, чтобы враги перехватили наше послание и прочитали его.

Поэтому мы с сообщником условились о специальном шифре. У меня есть книга (допустим «Пикник на обочине» Стругацких), и у него есть такая же книга. Я пишу письмо сначала простыми человеческими словами, а потом каждое слово заменяю на цифру. Например, цифра «137» будет обозначать, что данное слово находится на первой странице книги, на третьей строчке, седьмое слово по счету.

Мой сообщник получает письмо с цифрами «137-536-9978», берет свой томик Стругацких, и в обратной последовательности расшифровывает мое послание. Понятно, что даже если письмо будет перехвачено по дороге – никто не поймет, что там написано, потому что только мы с сообщником знаем, какую именно книгу мы используем для шифрования.

Вот и SSL протокол работает схожим образом. Только вы с сообщником каждого нового письма используете новую книгу. Кроме того, ваши книги – уникальны. То есть, нигде в мире больше нет ни одного экземпляра этой книги – только у вас и у сообщника.

Ну и, плюс ко всему, письмо вы отправляете не «Почтой России», а привязываете его к лапе самого быстрого ястреба, который летит от вас прямо по нужному адресу, и скорее погибнет, чем даст кому-то забрать у него ваше письмо.

Вы – это ваш сайт. Ваш сообщник – это ваш хостер-провайдер. Сообщение, которое вы передаете – это любая информация, которую пользователи вводят у вас на сайте – номера банковских карточек, пароли, емейлы и прочее. Быстрый ястреб-камикадзе – это прямой цифровой туннель для сообщения между вашим сайтом и сервером.

Такая работа через «уникальные книги» называется «SSL протоколом». А чтобы иметь возможность работать через этот протокол – вам надо сначала получить SSL сертификат. Это своеобразное удостоверение личности вашего сайта в интернете.

Можно ли взломать SSL протокол?

Теоретически, взломать можно даже эту сложную систему шифрования. То и дело на разных конференциях зачитываются доклады о том, как можно перехватывать сообщения по SSL, и как можно их расшифровывать.

Но на практике все эти способы либо очень сложные, либо очень долгие. То есть на расшифровку одной «буквы» послания может уйти до 2-3 часов времени. Естественно, такая «расшифровка» не сможет применяться для реального воровства ваших данных. И до сих пор SSL протокол считается «невзламываемым».

Но вот другой вопрос. Означает ли это, что ваш сайт и ваши данные в безопасности? Как ни удивительно, но вовсе не означает.

В чем главная опасность SSL сертификата?

То, что вы используете уникальные книги для шифрования, не значит, что злоумышленник не может притаиться где-нибудь на втором этаже вашего дома. В бинокль он увидит все, что вы пишите на листочке бумаги, и ему не придется даже ничего расшифровывать – он считает сообщение еще до того, как оно будет хитро зашифровано.

Точно так же и с сайтами. Наличие «https» у сайта не гарантирует, что на этом сайте нет вирусов или вредоносных программ. Такие программы могут считывать все, что вы вводите в поля платежной формы.

Кроме того, получить SSL сертификат сегодня очень просто. Самый распространенный вариант – это сертификат для подтверждения домена (так называемые DV – Domain Validation). То есть для его получения достаточно подтвердить, что у вас есть доступ к емейлу, на который зарегистрирован домен, вот и все. Никто не проверяет, что это за сайт, какой деятельностью он занимается, нет ли на нем вирусов.

Соответственно, любой хакер может сделать сайт, купить для него SSL (или даже взять бесплатный, их сейчас хватает) – и собирать ваши данные себе в копилку. Да, на его сервер они попадут в безопасности. Но куда они отправятся оттуда? Вопрос открытый.

И главной опасностью всей этой истории с SSL я считаю то, что у рядовых пользователей возникает ложное ощущение безопасности (либо наоборот — опасности), когда они видят, что сайт на https-протоколе (либо наоборот – на обычном «http»).

А масла в огонь подливает мой любимый Гугл.

Мол, и сайты-то без «https» мы будем помечать как «небезопасные» (читай – «мошеннические» с точки зрения пользователей), и как сигнал для SEO-ранжирования это включим. И все вебмастера в срочном порядке бросились переходить на SSL. Вот тут-то и открылась вся страшная правда.

Далеко не для всех сайтов SSL одинаково полезен. А во многих случаях даже вреден.

Нужен ли SSL сертификат для вашего сайта?

Если вы собираете важные личные данные посетителей сайта – такие как номера банковских карточек – то однозначно да. Вам обязательно нужно установить SSL протокол на свой сайт. Вы обязаны максимально обеспечить безопасностей людей на вашем ресурсе, иначе вы станете невольным пособником злоумышленников.

Вопрос в другом – надо ли вам заморачиваться со всеми этими сертификатами, если у вас не интернет-магазин, а обычный блог или информационный сайт? Принесет это вам какую-то пользу или наоборот? Да, к сожалению, может быть и наоборот.

Давайте я приведу здесь ТОП-3 мифов про SSL-сертификаты, которые распространены среди веб-мастеров.

Миф #1 – Гугл пометит мой сайт страшным красным значком, и все посетители с него убегут

На самом деле, Гугл давно стращает веб-мастеров тем, что в новой версии браузера Google Chrome все сайты без https будут помечаться как «небезопасные». Сначала они хотели ввести это в 53 версии своего браузера, потом в 58, потом в 62… Сейчас у меня установлена уже 63 версия Гугл Хром, и вот, что я вижу, когда открываю через него свой сайт (который работает на обычном «http»).

Вместо обещанного страшного красного значка висит круглый значок «i», который означает, что тут можно прочитать какую-то информацию. И если кликнуть по этому значку, тогда открывается сообщение, что подключение к сайту не защищено, и тут не надо оставлять личные данные.

То есть ничего страшного не показывается. А вдруг они начнут показывать «страшное» чуть позже, в 64 или 164 версии Хрома? Не начнут. Я в этом уверен по следующим причинам:

1. Гугл Хром помечает красными значками только те страницы, на которых есть реальные формы для ввода каких-то данных, а эти страницы не защищена SSL;
2. Гугл Хром показывает предупреждение «Не защищено», только когда вы начинаете вводить свои данные в форму. До этого момента она висит безо всяких предупреждений;
3. Если Гугл вдруг разом начнет запугивать посетителей обычных сайтов, то они на самом деле разбегутся. То есть Гугл потеряет всю свою поисковую выдачу, которую любовно выстраивал в течение многих лет. Это однозначно негативно скажется на качестве поисковой выдачи, и тогда пользователи разбегутся уже от самого Гугла (подтверждение моих слов смотрите чуть ниже).

То есть, другими словами, пока вы не собираете важные личные данные людей – Хрому нет никакого дела до того, на каком протоколе вы работаете.

Миф #2 – Гугл ставит выше в поиске сайты на https

Именно благодаря этому мифу во многом SSL-протокол получил такое широкое распространение. Веб-мастера вообще любят простые решения. Им сразу понравилась идея, что можно просто переехать на защищенный протокол, и тогда их сайты сразу «попрут» в гору. Не надо работать над качеством ресурса, не надо создавать ценный контент. Здорово же.

На самом деле, https нисколько не влияет на поисковую выдачу (по крайней мере в положительную сторону). Если отбросить весь треп, который стоит вокруг этой темы, и обратиться к первоисточнику (то есть к самому Гуглу), то мы увидим следующее.

В 2014 году Гугл потряс сообщество веб-мастеров сообщением о том, что теперь SSL будет учитываться как сигнал ранжирования. То есть буквально – сайты с SSL будут иметь приоритет при прочих равных.

Однако, влияние данного фактора будет очень незначительным – менее 1% от совокупности всех факторов ранжирования (а их у Гугла уже тысячи). Конечно, они пообещали, что далее вес данного фактора будет только увеличиваться и… замолкли на целых три года.

Официальных сообщений на эту тему больше не поступало. Сайты переезжали на https и дружно со свистом вылетали из индекса, а потом с большим трудом туда возвращались (хорошо, если вообще удавалось вернуть все свои позиции). А Гугл молчал.

В конце концов, в апреле 2017 году он объявил, что не намерен увеличивать вес данного фактора ранжирования. Перевод переписки между сотрудником Moz и представителем поиска Гугла на скриншоте ниже:

— Сейчас по нашим данным почти 50% сайтов в ТОПе Гугла используют SSL. Планируете ли вы дальше усиливать ранжирование в пользу защищенных сайтов?»

— Нет, мы рассмотрели эту идею несколько месяцев назад, и решили отказаться от неё»

Иначе говоря, для Гугла это был эксперимент – улучшится ли качество поисковой выдачи благодаря влиянию https или нет. Не улучшилась (и в самом деле, с чего бы?) Соответственно, от эксперимента отказались.

В качестве еще одного доказательства своей точки зрения я могу привести вам пример выдачи гугла по запросу «контент план».

Как вы видите сами, в ТОП-5 выдачи только один сайт имеет https протокол. И стоит он только на 4 месте. Все остальные сайты (включая мой на второй позиции) работают на обычном http, что нисколько им не мешает продвигаться.

При чем, обратите внимание, на https работает очень крупный и известный ресурс в нашей нише — Texterra. У этого сайта намного больше страниц, чем у меня, над ним трудится целая армия авторов и контент-менеджеров (а я пишу один), и этот сайт почти в два раза старше моего. То есть тут даже не «прочие равные». И если «https» — такой крутой фактор ранжирования, так поставьте его на первое место.

Но такого почему-то не происходит. Наверное, потому что для выхода на первые места одного SSL все-таки недостаточно.

Миф #3 – Переезд на SSL – это быстро и безопасно

На самом деле, это очень опасно и совсем не быстро. Если вы переезжаете с «http» на «https», то с точки зрения поисковых систем появляется абсолютно новый сайт. Вся его история обнуляется, все страницы надо заново индексировать, и выбирать им место в поиске.

А поисковые системы очень не любят, когда что-то так резко меняется на сайте. Гугл приводит список «best practice» переездов на https (то есть список кейсов, где переезд закончился удачнее всего). И знаете, какой результат считается самым успешным? Когда в течение 2-3 месяцев удается вернуть себе весь или почти весь трафик, который был до переезда.

То есть ни о каком качественном прорыве речи даже не идет. И никакой пользы в плане выдачи вы не получите.

А вот навредить своему сайту и себе можете очень даже запросто. Дело в том, что переезд на SSL – дело довольно тонкое. Если вы настроите что-то немножко не так, то ваш сайт вообще полностью вылетит из индекса очень надолго.

Например, вы можете неправильно настроить работу двух версий сайта – http и https, и тогда абсолютно на всех страницах будет выскакивать огромное предупреждение во весь экран – «Этот сайт небезопасен! Не удалось проверить сертификат! Немедленно уходим!»

Или вы можете «забыть» переделать ваши внутренние ссылки на сайте. Ведь после переезда они перестанут работать, соответственно вес сайта будет распределяться неправильно.

Или могут заблокировать организацию, которая выдала вам SSL сертификат. Тут уже не будет никакой вашей вины. Заблокировать сертификатора может даже Роскомнадзор за какую-нибудь провинность. И тогда ваш сертификат «обнулится», и опять «на дворе мочало – начинай с начала».

Резюмируем так: если у вас обычный блог или информационный сайт, то переезд на SSL ТОЧНО не принесет вам никакой пользы и выгоды, и ТОЧНО нанесет вам временный ущерб (а в половине случаев – постоянный ущерб).

Отсюда еще один интересный вопрос, чтобы закончить тему. Если SSL – это такая мутная штука, которая непонятно как выстрелит – почему тогда вокруг столько шума о необходимости немедленного переезда на https?

Кому выгодно, чтобы у вас был SSL?

Как всегда, если какая-то мистификация получает широкое распространение – значит есть те, кому это выгодно.

В нашем случае это многочисленные хостер-провайдеры, которые сразу почуяли запах денег. Одно дело – брать с вас деньги каждый год только за хостинг, а другое – еще и за SSL сертификат. Естественно они будут уверять всех и вся, что SSL – это жизненная необходимость. Вон, мол, сам Гугл это подтверждает.

Мне часто пишут вебмастера с вопросами про этот SSL. И говорят, что впали в паническое состояние после какой-нибудь веб-конференции, где им рассказывали про преимущества SSL. После пары вопросов всегда выясняется, что данный доклад делали представители компании, которая как раз занимается продажами SSL-сертификатов. Кто бы мог подумать.

Тут я не могу удержаться и не показать вам одно видео от компании, занимающейся продажами SSL. Это просто шедевр трэш-контента =) И по этому видео прекрасно видно, как такие хостинг-провайдеры относятся к своим клиентам – как к безмозглым животным))

Заключение

Конечно, только вам решать, нужен вам SSL сертификат или нет. Я могу только кратко резюмировать:

• SSL – действительно хороший способ шифрования, который пока на практике никому не удалось взломать;
• Наличие SSL сертификата не гарантирует, что сайт безопасен. На нем могут быть вирусы и вредоносные программы, которые перехватывают данные до отправки на сервер;
• Если вы занимаетесь электронной коммерцией, то вам обязательно надо ставить SSL сертификат (либо для совершения транзакций отправлять посетителей на сторонний защищенный ресурс платежной системы, как это делаю, например, я);
• Гугл не помечает сайт без SSL как «небезопасные», и не будет этого делать, потому что так он навредит сам себе;
• Наличие SSL никак не влияет на положение в поисковой выдаче вашего сайта;
• При переезде с «http» на «https» очень высока вероятность где-нибудь ошибиться, и тогда ваш сайт может вообще никогда до конца не восстановить свои позиции;
• Больше всего паники среди вебмастеров наводят хостер-провайдеры, потому что они зарабатывают деньги на продаже SSL-сертификатов.

Другими словами – если у вас новый сайт и вам нечего терять, то вы можете спокойно сразу сделать его на https. Главное купите его у надежного провайдера. А то поставщиков разных бесплатных SSL скорее заблокируют, и вам тогда будет очень плохо.

А если у вас ресурс уже раскручен и вы не принимаете платежи непосредственно на сайте – скорее всего он вам и даром не нужен. Пишите статьи и выходите в ТОП без него. А можете просто использовать отдельный сайт на «https» для приема платежей.

Надеюсь, статья была для вас полезной. Не забудьте скачать мою книгу . Там я показываю вам самый быстрый путь с нуля до первого миллиона в интернете (выжимка из личного опыта за 10 лет =)

До скорого!

Ваш Дмитрий Новосёлов

Протокол обеспечивает конфиденциальность обмена данными между клиентом и сервером, использующими TCP/IP, причём для шифрования используется асимметричный алгоритм с открытым ключом . При шифровании с открытым ключом используются два ключа, открытый и секретный, причем любой из них может использоваться для шифрования сообщения. Если для шифрования сообщения был использован открытый ключ, то для расшифровки должен использоваться секретный, и наоборот. В такой ситуации возможны два способа использования ключей. Во-первых, сторона, хранящая в тайне секретный ключ и опубликовавшая открытый, может принимать от противоположной стороны сообщения, зашифрованные открытым ключом, которые не может прочитать никто, кроме нее (ведь для расшифровки требуется секретный ключ, известный только ей). Во-вторых, с помощью закрытого ключа сторона-обладатель закрытого ключа может создавать зашифрованные сообщения, которые может прочесть кто угодно (ведь для расшифровки нужен открытый ключ, доступный всем), но при этом прочитавший может быть уверен, что это сообщение было создано стороной-обладателем секретного ключа.

Описание

Протокол SSL состоит из двух подпротоколов: протокол SSL записи и рукопожатия. Протокол SSL записи определяет формат, используемый для передачи данных. Протокол SSL включает рукопожатие с использованием протокола SSL записи для обмена сериями сообщений между сервером и клиентом во время установления первого соединения. Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат .

SSL предоставляет канал, имеющий 3 основных свойства:

• Аутентификация. Сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма.
• Целостность. Обмен сообщениями включает в себя проверку целостности.
• Конфиденциальность канала. Шифрование используется после установления соединения и используется для всех последующих сообщений.

В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то запись не имеет заполнителя и полная длина заголовка равна двум байтам, иначе запись содержит заполнитель и полная длина заголовка равна трём байтам. Код длины записи не включает в себя число байт заголовка. Длина записи 2-байтового заголовка:

RecLength = ((byte[ 0 ] & 0x7F ) << 8 ) | byte[ 1 ] ;

Здесь byte и byte - первый и второй полученные байты. Длина записи 3-байтового заголовка:

RecLength = ((byte[ 0 ] & 0x3F ) << 8 ) | byte[ 1 ] ; Escape = (byte[ 0 ] & 0x40 ) != 0 ; Padding = byte[ 2 ] ;

Здесь Padding определяет число байтов, добавленных отправителем к исходному тексту, для того, чтобы сделать длину записи кратной размеру блока шифра, при использовании блочного шифра.
Теперь отправитель «заполненной» записи добавляет заполнитель после имеющихся данных и шифрует всё это. Причем, содержимое заполнителя никакой роли не играет. Из-за того, что известен объём передаваемых данных, заголовок может быть сформирован с учетом Padding.
В свою очередь получатель записи дешифрует все поля данных и получает полную исходную информацию. Затем производится вычисление значения RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3 компонент:

• MAC_Data - (Message Authentication Code) - код аутентификации сообщения
• Padding_Data - данные заполнителя
• Actual_Data[N] - реальные данные

Когда записи посылаются открытым текстом, очевидно, что никакие шифры не используются. Тогда длина Padding_Data и MAC_Data равны нулю. При использовании шифрования Padding_Data зависит от размера блока шифра, а MAC_Data зависит от выбора шифра. Пример вычисления MAC_Data:

MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number) ;

Значение Secret зависит от того, кто (клиент или сервер) посылает сообщение. Sequence_Number - счётчик, который инкрементируется как сервером, так и клиентом. Здесь Sequence_Number представляет собой 32-битовый код, передаваемый хэш-функции в виде 4 байт, причём, первым передаётся старший байт. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2-байтового заголовка максимальная длина записи равна 32767 байтов, а для 3-байтного заголовка - 16383 байтов.

История и развитие

Протокол SSL был изначально разработан компанией Netscape. Версия протокола 1.0 публично не выпускалась. Версия 2.0 была выпущена в феврале 1995 года, но «содержала много недостатков по безопасности, которые, в конечном счёте, привели к созданию версии 3.0», которая была выпущена в 1996 году. Тем самым версия SSL 3.0 послужила основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF) впервые был определен в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации, работающие с интернет деньгами, имеют лицензию на использование протокола SSL для коммерческих целей в сети Интернет.

SSL работает модульным способом. Тем самым SSL расширяемо в соответствии с проектом о поддержке прямой и обратной совместимости и переговорам между соединениями в одноранговой сети.

Применение

Значительное использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS , «упаковываются» в криптографический протокол SSL или TLS , тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. HTTPS поддерживается всеми браузерами. В отличие от HTTP , для HTTPS по умолчанию используется TCP -порт 443.

Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте.

Основные цели протокола в порядке приоритетности

1. Криптографическая безопасность: SSL устанавливает безопасное соединение между двумя сторонами.
2. Совместимость: Программисты, независимо друг от друга могут создавать приложения, использующие SSL, которые впоследствии будут способны успешно обмениваться криптографическими параметрами без всякого знания кода чужих программ.
3. Расширяемость: SSL стремится обеспечить рабочее пространство, в котором новые открытые ключи и трудоемкие методы шифрования могут быть включены по мере необходимости.
4. Относительная эффективность: работа протокола на основе SSL требует больших скоростей от CPU, в частности для работы с открытыми ключами. По этой причине SSL протокол был включен в необязательную сессию схемы кеширования для уменьшения числа соединений, которые необходимо устанавливать с нуля. Кроме того, большое внимание уделяется тому, чтобы уменьшить сетевую активность.

Аутентификация и обмен ключами

SSL поддерживает 3 типа аутентификации:

• аутентификация обеих сторон (клиент - сервер),
• аутентификация сервера с неаутентифицированным клиентом
• полная анонимность.

Всякий раз, когда сервер аутентифицируется, канал безопасен против попытки перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами - это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». При посылке верного сообщения «finished», тем самым стороны докажут что они знают верный секрет (pre_master_secret).

Анонимный обмен ключами

Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret).

Обмен ключами при использовании RSA и аутентификация

В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA , который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура включает текущее значение сообщения Client_Hello.random, таким образом старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ соответствующий сертификату сервера.

Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия включают сертификат сервера, который ставит в соответствие сигнатуре сервера, сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.

Обмен ключами при использовании Diffie-Hellman и аутентификация

В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием, для того чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру, для уверенности, что параметры принадлежат серверу.

Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman , то сертификат также содержит информацию требуемую для того чтобы завершить обмен ключами. Заметим, что в этом случае клиент и сервер должны будут сгенерировать те же Diffie-Hellman результаты (pre_master_secret), каждый раз когда они устанавливают соединение. Для того чтобы предотвратить остановку секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, на сколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.

Протокол записи (Record Layer)

Протокол записи - это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи: протокол рукопожатия (handshake protocol), протокол тревоги (alert protocol), протокол изменения шифра (the change cipher spec protocol), протокол приложения (application data protocol). Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Любой протокол созданный для использования совместно с SSL должен быть хорошо продуман, так как будет иметь дело с атаками на него. Заметим, что из-за типа и длины записи, протокол не защищен шифрованием. Внимание следует уделить тому, чтобы минимизировать трафик.

Протокол рукопожатия (handshake)

SSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия. Во время рукопожатия клиент и сервер договариваются о различных параметрах, которые будут использованы, чтобы обеспечить безопасность соединения.

• Рукопожатие начинается тогда, когда клиент подключается к SSL серверу. Запрос безопасного соединения представляет собой список поддерживаемых шифров и хэш-функций.

• Из этого списка сервер выбирает самый сильный шифр и хэш-функцию, которую он также поддерживает, и уведомляет клиентов о принятом решении.

• Сервер отсылает это решение в виде цифрового сертификата. Сертификат, обычно, содержит имя сервера, доверенный Центр Сертификации, и открытый ключ шифрования сервера. Клиент может связаться с сервером, который выдал сертификат (доверенного центра сертификации, выше) и убедиться, что сертификат является подлинным прежде чем продолжить.

• Для того, чтобы сгенерировать ключи сеанса, используется безопасное соединение. Клиент шифрует случайное число с помощью открытого ключа (ОК) сервера и отправляет результат на сервер. Только сервер в состоянии расшифровать его (с его закрытым ключом (ЗК)), и только этот факт делает ключи скрытыми от третьей стороны, так как только сервер и клиент имели доступ к этим данным. Клиент знает открытый ключ и случайное число, а сервер знает закрытый ключ и (после расшифровки сообщения клиента) случайное число. Третья сторона, возможно, знает только открытый ключ, если закрытый ключ не был взломан.

• Из случайного числа обе стороны создают ключевые данные для шифрования и расшифровывания.

На этом рукопожатие завершается, и начинается защищенное соединение, которое зашифровывается и расшифровывается с помощью ключевых данных. Если любое из перечисленных выше действий не удается, то рукопожатие SSL не удалось, и соединение не создается.

Протокол изменения параметров шифрования (The Change Cipher Spec Protocol)

Он существует для сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато при текущем установленном соединении. Сообщение состоит только из одного бита со значением 1.

Struct { enum { change_cipher_spec(1 ) , (255 ) } type; } ChangeCipherSpec;

Сообщение изменения шифра посылается и клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение ‘finished’.

Протокол тревоги (Alert Protocol)

Один из типов проверки, поддерживаемых в протоколе SSL записи, - это протокол тревоги. Сообщение тревоги передаёт трудности, возникшие в сообщении, и описание тревоги. Сообщение тревоги с критическим уровнем незамедлительно прерывает соединение. В этом случае другие соединения, соответствующие сессии, могут быть продолжены, но идентификатор сессии должен быть признан недействительным. Как и другие сообщения, сообщение тревоги зашифровано и сжато, как только указано текущее состояние соединения.

Протокол приложения (Application Data Protocol)

Сообщение приложения данных работает на уровне записи. Он фрагментируется, сжимается и шифруется на основе текущего состояния соединения. Сообщения считаются прозрачными для уровня записи.

Ошибки в протоколе SSL

В протоколе SSL обработка ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера и клиента разрыва соединения. Протокол SSL определяет следующие ошибки:

1. Unsupported_Certificate_Type_Error : такая ошибка возникает, когда клиент/сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента).
2. No_Cipher_Error : ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и клиентом. Ошибка неустранима.
3. Bad_Certificate_Error : такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента).
4. No_Certificate_Error : если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима.

Атаки

Существует ряд атак, которые могут быть предприняты против протокола SSL. Однако SSL устойчив к этим атакам, при условии, что пользователь использует только доверенные сервера для обработки информации.

"Взлом" агентами ФБР SSL-соединений с помощью систем прослушки Carnivore и NarusInsight

Наиболее известный инцидент по массовому "взлому" информации защищенной SSL-протоколами был произведен агентами ФБР с помощью систем Carnivore и NarusInsight , что привело к судебному процессу от лица правозащитной организации Electronic Frontier Foundation против AT&T (подробнее в статье о NarusInsight), который установил данные комплексы для взлома криптографически защищенной информации.

Несмотря на высокий общественный резонанс в США данного дела и расследование на уровне конституционного комитета Палаты представителей (см. подробнее в статье Carnivore), технологически взлом протокола SSL агентами ФБР не производился. Carnivore и NarusInsight были установле в самом ЦОД , где находились сервера ведущие SSL-соединенения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путем прослушивания не SSL-соединения, а внутреннего траффика между серверами приложений внутри самого ЦОД , уже после того как данные поступившие по SSL была расшифрованы сами сервером их принявшим от внешних пользователей.

Тем не менее, указанный инцидент показал, что SSL не может являться надежным средством криптозащиты данных серверов в Интернет покуда спецслужбы устанавливают системы прослушивания в ЦОД такие как NarusInsight или СОРМ-2 . Любой вид криптографии подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируется и законодательными актами такими как "Патриотический акт ". Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцов ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, SSL-протокол может защищать только соединение двух пользователей в Интернет, но не защищает от спецслужб любое SSL-соединение с внешним Web-сайтом.

Раскрытие шифров

Как известно, SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA.

Злоумышленник посередине

Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации.

Атака будет успешной, если:

• Сервер не имеет подписанного сертификата.
• Клиент не проверяет сертификат сервера.
• Пользователь игнорирует сообщение об отсутствии подписи сертификата центром сертификации или о несовпадении сертификата с кэшированным.

Данный вид атаки можно встретить в крупных организациях, использующих межсетевой экран Forefront TMG компании Microsoft. В данном случае "злоумышленник" находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного корневого центра сертификации сам Forefront TMG. Обычно подобная процедура внедрения проходит прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS.

Наиболее спорным становится вопрос информированности пользователя о возможности перехвата данных, т.к. в случае подмены корневого сертификата никаких сообщений безопасности выводиться не будет и пользователь будет ожидать конфиденциальности передаваемых данных. Кроме того, при использовании Forefront TMG в качестве SSL-прокси возникает возможность проведения второй MitM-атаки на стороне интернета, т.к. оригинальный сертификат не будет передан пользователю, а Forefront TMG может быть настроен на прием и последующую подмену самоподписанных или отозванных сертификатов. Для защиты от подобной атаки необходимо полностью запретить работу с веб-серверами, чьи сертификаты содержат какие-либо ошибки, что безусловно приведет к невозможности работы по протоколу HTTPS со множеством сайтов.

Атака отклика

Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать кодов nonce, чтобы получить вероятность угадывания 50 %. Но достаточно большое число, что делает эти атаки бессмысленными.

Атака против протокола рукопожатия

Злоумышленник может попытаться повлиять на обмен рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования, а не те, что они выбирают обычно. Из-за того, что многие реализации поддерживают 40-битное экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес.

Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения Finished . Без знания секрета злоумышленник не сможет исправить сообщение Finished , поэтому атака может быть обнаружена.