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

Бимал Шах, Айя Загуль, 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 (англ. 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)

Что такое HTTPS?

Все наши запросы в Интернете представляют собой обмен данными. Информация от пользователя к серверу и обратно поступает по открытому протоколу передачи данных HTTP (HyperText Transfer Protocol). Он лежит в основе работы сети. Однако у HTTP есть недостаток — отсутствие защиты шифрованием. Из-за этого личная информация пользователей (пароли, номера банковских карт, паспортные данные) может быть украдена третьими лицами. Для защиты информации был внедрён HTTPS — протокол безопасного соединения.

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

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

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

Все популярные браузеры поддерживают шифрованное соединение. Чтобы узнать, работает ли сайт по HTTPS, присмотритесь к URL в адресной строке. Если адрес начинается с https:// и перед ним отображается зелёный замок, разработчик сайта позаботился о безопасности пользовательских данных:

Где применяется HTTPS?

В настоящее время использование протокола HTTPS — признак хорошего тона. HTTPS демонстрирует посетителям сайта, что они могут без опасений оставлять на нём личную информацию и совершать транзакции. Также он служит для SEO-продвижения проекта — позволяет занять более высокую позицию в поисковой выдаче. Поисковые системы (Google, Яндекс и пр.) дорожат доверием аудитории и выше ранжируют сайты, которые работают через безопасное соединение.

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

Установка SSL-сертификата на сайт гарантирует:

• подлинность соответствия ресурса подписям в сертификате, что положительно сказывается на уровне доверия посетителей к вашему сайту;
• целостность передаваемой информации. На время передачи информации от сервера к браузеру гарантируется отсутствие изменений или потерь данных;
• конфиденциальность . За счёт использования 256-разрядного шифрования данных информация, передаваемая между вашим сервером и браузером посетителя, недоступна для просмотра и изменения посторонним лицам.

Как перейти с HTTP на HTTPS?

Если ваш сайт обслуживается на хостинге сайт, выполните следующие шаги:

1. 1 Закажите SSL-сертификат или подключите бесплатный SSL-сертификат при регистрации домена или услуги хостинга в сайт. Подробнее о заказе SSL читайте в разделе .
2. 2 Активируйте сертификат по соответствующей инструкции из раздела

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