Бимал Шах, Айя Загуль, IBM

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

Протокол SSL (Secure Socket Layers - протокол защищенных сокетов), совместно разработанный Netscape Communications и RSA Data Security, позволяет эффективно обеспечить такую безопасность. Протокол SSL обеспечивает безопасность, аутентификацию на базе сертификатов и согласование безопасности по установленному сетевому соединению, поэтому множество компаний и продуктов приняли SSL в качестве коммуникационного протокола.

В этой серии мы сконцентрируемся на двух главных аспектах:

1. подробная информация о схеме работы SSL;
2. детальная информация о поддержке SSL в версиях 5.1 и 6.0.1 среды ISC.

В данной статье исследуется SSL и объясняется, почему его рекомендуется реализовать в среде ISC. Во второй и третьей частях этой серии будет представлена подробная пошаговая инструкция по реализации и подключению SSL к ISC 5.1 и 6.0.1.

Реализация протокола SSL, используемая в WebSphere® Application Server, хранит персональные сертификаты в файле ключей SSL и сертификаты издателя в файле со списком доверенных источников. Файл ключей содержит коллекцию сертификатов, каждый из которых может быть представлен во время установки SSL соединения для подтверждения подлинности. В файле со списком доверенных источников хранится коллекция сертификатов, которые считаются достоверными и с которыми будет сравниваться представленный сертификат во время установки SSL-соединения для проверки подлинности.

Хорошим примером реализации протокола SSL является его поддержка в IBM WebSphere Application Server. Система безопасности этого сервера имеет многоуровневую архитектуру, показанную на рисунке 2.

Уровень сетевой безопасности обеспечивает аутентификацию на транспортном уровне, целостность и шифрование сообщений. Коммуникации между различными серверами WebSphere Application Server могут быть сконфигурированы на использование протоколов SSL и HTTPS. Для дополнительной защиты сообщений также можно использовать протоколы IP Security и VPN (Virtual Private Network - виртуальная частная сеть).

Протокол SSL обеспечивает безопасность на транспортном уровне: аутентификацию, целостность и конфиденциальность для безопасного соединения между клиентом и сервером в WebSphere Application Server. Этот протокол работает поверх TCP/IP и под прикладными протоколами, такими как HTTP, LDAP, IIOP, обеспечивая достоверность и секретность передаваемых данных. В зависимости от конфигурации SSL на клиенте и сервере могут быть установлены различные уровни достоверности, целостности данных и секретности. Понимание основ функционирования протокола SSL очень важно для правильной настройки и достижения требуемого уровня защиты для данных клиента и приложения.

Некоторые функции безопасности, предоставляемые протоколом SSL:

• Шифрование данных с целью предотвратить раскрытие конфиденциальных данных во время передачи.
• Подписывание данных с целью предотвратить несанкционированное изменение данных во время передачи.
• Аутентификация клиента и сервера, позволяющая убедиться, что общение ведется с соответствующим человеком или компьютером.

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

Протокол SSL используется различными компонентами внутри WebSphere Application Server для обеспечения достоверности и конфиденциальности. К этим компонентам относятся: встроенный HTTP-транспорт, ORB и безопасный LDAP-клиент.

Реализация SSL, используемая в WebSphere Application Server, - это либо расширение для Java - IBM Java™ Secure Sockets Extension (IBM JSSE), либо IBM System SSL. Провайдер IBM JSSE содержит эталонную реализацию, поддерживающую протоколы SSL и TLS (Transport Layer Security - безопасность транспортного уровня) и API для интеграции. С провайдером IBM JSSE также поставляется стандартный провайдер, предоставляющий поддержку RSA для функциональности цифровой подписи из библиотеки JCA (Java Cryptography Architecture - Архитектура Шифрования для Java) для платформы Java 2, стандартные наборы шифров для SSL и TLS, менеджеров доверенных источников сертификатов и ключей, использующих технологию X509, и реализацию технологии PKCS12 для хранилища цифровых сертификатов JCA.

Конфигурация провайдера JSSE очень похожа на конфигурацию большинства других реализаций SSL, например GSKit, однако пару отличий следует выделить:

• Провайдер JSSE поддерживает хранение собственного сертификата и сертификатов издателя в файле ключей SSL, но он также поддерживает и отдельный файл, т.н. файл источников сертификатов (trust file). Этот файл может содержать только сертификаты источников. Можно поместить свои собственные сертификаты в файл ключей SSL, а сертификаты издателей - в trust-файл. Это может потребоваться, например, при наличии недорогого аппаратного криптографического устройства, у которого памяти достаточно только для хранения персонального сертификата. В этом случае файл ключей указывает на аппаратное устройство, а trust-файл указывает на файл на диске, содержащий все сертификаты издателей.
• Провайдер JSSE не распознает специальный формат файла ключей SSL, используемый плагином - файлы с расширением.kdb. Провайдер JSSE распознает только стандартные форматы файлов, такие как Java Key Store (JKS - хранилище ключей Java). Совместное использование файлов ключей SSL плагином и сервером приложений невозможно. Более того, для управления ключами сервера приложений и trust-файлами необходимо использовать различные реализации утилиты управления ключами.

SSL и Integrated Solutions Console

Приложение ISC - это единая среда Web-консолей администрирования для развертывания и интеграции консольных модулей, позволяющая заказчикам управлять решениями, а не конкретными продуктами IBM. Эта среда включает в себя контейнер портлетов, Java-компоненты (JMX) для управления приложениями и модули справки Eclipse.

Для реализации конфиденциальности и шифрования можно использовать протокол SSL. С помощью SSL можно защитить взаимодействие между Web-браузером пользователя и сервером ISC. Шифрование важно потому, что в ISC используется аутентификация, основанная на формах; при этом идентификатор и пароль пользователя для входа в систему не шифруются при пересылке по сети. Если консольному модулю требуется доступ к внутренним ресурсам через безопасное соединение, его портлеты могут использовать SSL.

Какие преимущества дает использование SSL?

Почему это так важно? Безопасная и эффективная передача данных по открытым коммуникационным каналам - это критический компонент обеспечения функционирования современной ИТ-системы, и протокол SSL позволяет обеспечить эту безопасность. Однако подключение SSL к среде ISC может оказаться сложной и трудоемкой задачей. В чем сложность этой задачи? Вопрос безопасности данных в среде Web-приложений, подобных среде Integrated Solutions Console, может показаться немного размытым для новичков, потому что безопасность ИТ сама по себе - крайне широкая область, охватывающая много различных аспектов в открытых коммуникационных сетях.

В следующих двух статьях этой серии будет представлена организация безопасности данных на основе SSL в среде, основанной на Integrated Solutions Console. Сначала мы рассмотрим настройку и включение SSL для Integrated Solutions Console 5.1 с использованием пустого, собственного и выпущенного издателем сертификатов, а потом разберем, как выполнить те же действия для Integrated Solutions Console 6.0.1.

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

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

Кроме того, SSL-сертификат позволяет пользователю проверить, кто является владельцем сайта. Это значит, что пользователь может удостовериться, что он зашел на сайт нужной ему организации, а не на сайт ее двойника.

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

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

В целях безопасности SSL-сертификат не переносится на другой договор.

Проверить принадлежность домена в заказе на сертификат можно через электронную почту, указанную для домена в Whois сервисе. Для этого вам нужно обратиться к регистратору домена и прописать в Whois сервисе для него любую электронную почту. Если домен зарегистрирован в RU-CENTER, то для этого укажите почту в личном кабинете:

1. В выберите Услуги → Мои домены .
2. Нажмите на доменное имя как на активную ссылку.
3. В строке Описание в Whois нажмите ссылку Изменить .
4. Укажите электронную почту и нажмите кнопку Сохранить изменения . После этого уведомьте нас о проделанных действиях по адресу .

Если запрос на сертификат CSR вы генерировали в личном кабинете RU-CENTER (была выбрана опция «создать CSR»), то закрытый ключ сохранился автоматически на вашем компьютере с именем файла privatekey.txt. Попробуйте выполнить поиск на компьютере. Без сохранения файла вы не могли бы перейти на следующий шаг при подаче заказа на сертификат. Если же запрос на сертификат CSR был сгенерирован на вашем сервере или у стороннего хостинг-провайдера, то закрытый ключ находится на сервере или у провайдера соответственно. Если закрытый ключ утерян, то необходимо выполнить - это бесплатно.

1. Зайдите на сайт https://www.upik.de .
2. Выберите язык English .
3. Нажмите ссылку UPIKR-Search with D-U-N-SR number .
4. В поле D&B D-U-N-SR Number введите номер DUNS.
5. В поле Select country выберите страну.
6. На открывшейся карточке компании вы можете проверить наличие номера телефона в поле Telephone number .

Если номер телефона указан некорректно или отсутствует, обратитесь в российское представительство DUN&BRADSTREET - компанию Интерфакс , и внесите или откорректируйте номер телефона в карточке компании. После внесения изменений номер телефона по вашему DUNS будет отображаться только через 7-30 календарных дней.

Чтобы изменить список доменов, на которые распространяется сертификат, необходимо заново создать CSR и пройти процедуру перевыпуска сертификата:

1. В разделе Для клиентов → SSL-сертификаты и выберите нужный сертификат.

3. Если вы хотите создать CSR в процессе заказа - нажмите Продолжить .Если вы будете использовать свой CSR - введите его в появившемся поле. Создание CSR для установки сертификата на Microsoft IIS описано в отдельных инструкциях - они откроются при выборе этого варианта.

4. Внесите изменения в список доменов и нажмите Продолжить .

5. Укажите контактные данные и нажмите Продолжить .

6. Сохраните приватный ключ - он понадобится для установки сертификата на веб-сервер. Нажмите Продолжить .

7. Проверьте корректность и нажмите Отправить заказ .

SSL-сертификаты выпускаются на срок 1-2 года.

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

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

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

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

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

Обычное интернет-соединенение проходит примерно через 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-сертификата на сайте позволяет значительно повысить безопасность и конфиденциальность информации, передаваемой между сайтом (сервером) и клиентом (браузером), путем использования криптостойкого алгоритма шифрования.

Для чего нужен сертификат?

«Замок» и приставка https в адресной строке выступают в роли своеобразного маяка для потенциальных клиентов вашего, например, интернет-магазина. Посетители подобных сайтов могут быть уверены в том, что их персональные и конфиденциальные данные (например, ФИО, адрес доставки, номер и CVV2 код кредитной карты) не попадут в руки злоумышленников, что станет весомым аргументом в пользу выбора именно вашей площадки.

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

Использование SSL на сайте является весомым показателем для поисковых систем, которые отдают таким площадкам приоритет в поисковой выдаче.

Как работает SSL?

Работа защищенного протокола базируется на связке типа «запрос-ответ» между сайтом и браузером клиента:

1. Браузер клиента отправляет сайту запрос на получение страницы по защищенному протоколу HTTPS.
2. В ответ сервер посылает копию своего сертификата SSL.
3. Браузер осуществляет проверку подлинности полученного сертификата, после чего отправляет серверу свой публичный ключ.
4. Сервер проводит шифрование запрашиваемой страницы полученным ключом и отправляет ее браузеру клиента.
5. Надежное соединение по защищенному протоколу HTTPS с использованием SSL установлено. Все запросы шифруются.

Виды SSL-сертификатов

Современные сервисы (удостоверяющие центры) по выдаче SSL-сертификатов для сайта предлагают варианты, предназначенные для:

1. Проверки домена. К этому типу относятся самые простые сертификаты, подтверждающие права на владение доменным именем.
2. Подтверждения данных организации и права использования домена.
3. Защиты субдоменов. Подобный вид SSL обеспечивает защиту не только основного домена, но и всех его поддоменов.
4. Для использования на нескольких сайтах. Мультидоменный SAN SSL-сертификат можно использовать на нескольких сайтах (до 250!).

Срок действия «сертификатов надежности»

Каждый веб-мастер может заказать SSL-сертификат на срок от 1 до 3 лет. Важно понимать, что датой активации сертификата является день его выпуска, а не день заказа. Это говорит о том, что, например, заказав сертификат для своего домена 1 февраля 2017 года, вы получили его только 12 февраля (проверка всех документов отняла какое-то время). Это значит, что днем начала действия SSL-сертификата является 12 февраля 2017 года, а днем окончания - 11 февраля 2018.

Вывод

Вы являетесь владельцем онлайн-магазина? Занимаетесь электронной коммерцией? Вы получаете конфиденциальную информацию от клиентов или передаете ее другим с помощью сайта? Просто хотите подтолкнуть свой проект поближе к топу поисковой выдачи Google или Яндекс? Тогда SSL-сертифицирование сайте - это то, что нужно. Как говорится, must have.

Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования . Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера - говорим об управленческих аспектах и возможностях для улучшения usability сервиса .

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

SSL (secure sockets layer - уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security - безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.

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

Рукопожатие

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

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

Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.

Алгоритмы шифрования

Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных - 64.

Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.

Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан . Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.

Сертификаты бывают разные

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

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

Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.

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

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

Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.