Ssl, что это?

Часть 1. Что такое протокол SSL и зачем он нужен?

SSL и ISC

Обеспечение безопасности данных в открытых коммуникационных каналах при работе с ISC

Бимал Шах и Айя Загуль
Опубликовано 12.02.2008

Серия контента:

Этот контент является частью # из серии # статей: SSL и ISC

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=ssl+и+isc Следите за выходом новых статей этой серии.

Этот контент является частью серии:SSL и ISC

Следите за выходом новых статей этой серии.

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

Протокол 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?

Знакомство с SSL

Протокол SSL обеспечивает целостность и конфиденциальность обмена данными между двумя общающимися приложениями, использующими TCP/IP. Данные, перемещающиеся между клиентом и сервером, шифруются симметричным алгоритмом.

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

Цифровые сертификаты

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

  • установить личность владельца;
  • сделать доступным первичный ключ владельца.

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

Цифровой сертификат содержит следующие фрагменты информации о личности владельца сертификата и источнике сертификатов:

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

Подключение по SSL всегда инициируется клиентом вызовом URL-адреса, начинающегося с https:// вместо http://.

Типы сертификатов

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

Есть три способа получить SSL-сертификат:

  1. использовать сертификат от источника сертификатов;
  2. использовать самоподписанный сертификат;
  3. использовать «пустой» сертификат

Использование сертификата от источника сертификатов

Источники сертификатов (CA) — это организации, которым доверяет вся отрасль и которые занимаются выдачей Интернет-сертификатов. Например, такой сертификат можно получить от компании VeriSign. Чтобы получить сертификат, подписанный источником, необходимо предоставить достаточно информации источнику, чтобы он смог проверить вашу личность. Тогда источник создаст новый сертификат, подпишет его и доставит его вам. Популярные Web-браузеры заранее настроены доверять сертификатам, выданным определенными источниками, так что не нужно никакой дополнительной конфигурации для подключения клиента через SSL к серверу, для которого был выдан сертификат.

Использование самоподписанного сертификата

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

Использование «пустого» сертификата

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

Итак, что нужно делать после получения сертификата?

Аутентификация на стороне клиента или сервера

После того как сертификат был получен, необходимо установить его подлинность (аутентифицировать). В протоколе SSL есть два типа аутентификации:

  • аутентификация на стороне клиента;
  • аутентификация на стороне сервера.

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

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

На рисунке 1 приведена диаграмма, иллюстрирующая этот процесс.

Рисунок 1. Процесс аутентификации между клиентом и сервером

Файл ключей и файл со списком доверенных источников

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

SSL и WebSphere Application Server

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

Рисунок 2. Многоуровневая безопасность WebSphere Application Server

Кликните, чтобы увидеть увеличенное изображение

Уровень сетевой безопасности обеспечивает аутентификацию на транспортном уровне, целостность и шифрование сообщений. Коммуникации между различными серверами 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 on ISC, Part 1: What is SSL and why should I care? (EN): оригинал статьи.
  • Self-signed server certificate (EN): пошаговая инструкция по созданию собственного сертификата
  • IBM Workplace Collaboration Services information center (EN): в этой статье объясняется, какие компоненты в различных Web-браузерах требуют подписанных проверенных сертификатов.
  • WebSphere Application Server and IBMJSSE (EN) — на этой странице ресурса InfoCenter приведена дополнительная информация по SSL.
  • Launch the ISC console thru Web Browser (EN): в этой статье показано, как запустить Integrated Solutions Console через Web-браузер после установки.(EN)
  • Embed the Integrated Solutions Console installation (EN) (developerWorks, март 2005 г.): эта статья демонстрирует, как с помощью установщика встраивать Integrated Solutions Console в другие продукты.
  • Дополнительная информация по Java, продуктам Tivoli и WebSphere products, Eclipse, безопасности а также безопасности имеется в соответствующих разделах сайтов developerWorks и alphaWorks.
  • Скачайте версию Integrated Solutions Console и ознакомьтесь с дополнительной информацией об этом продукте в Autonomic Computing Toolkit.(EN)
  • WebSphere Application Server 6.1 — это платформа для приложений на базе Java 2 Enterprise Edition и Web-сервисов. Кроме обычной версии, предлагаются также версия Express (включающая сервер приложений J2EE, примеры приложений, инструменты разработчика и мастера), а также бесплатная упрощенная версия Community Edition.(EN)

Что такое SSL-сертификат и чем он опасен

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

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

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

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

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

  • значок закрытого замка, при нажатии на который вы увидите фразу «Безопасное соединение», а также сможете получить более подробную информацию об установленном сертификате;
  • либо рядом с значком замочка будет также указано название компании-собственника сайта.

Если же на сайте SSL-сертификат не установлен, то перед адресом будет написано «Не защищено».

Разница между HTTP и HTTPS

HTTP — это протокол прикладного уровня, который используется для передачи данных в сети. Этот протокол дает возможность передавать запросы от клиента к серверу и получать от сервера ответы на эти запросы.

Что касается HTTPS, то это не другой отдельный протокол, а расширение протокола HTTP. Это можно понять уже по расшифровке аббревиатур:

  • HTTP — HyperText Transfer Protocol (в переводе «протокол передачи гипертекста»);
  • HTTPS — HyperText Transfer Protocol Secure (в переводе «защищенный протокол передачи гипертекста»).

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

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

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

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

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

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

Как уже было сказано, SSL расшифровывается как “Secure Sockets Layer” (уровень защищенных сокетов). Именно этот протокол позволяет зашифровать данные, передающиеся между компьютером пользователя и веб-сайтом. И для работы именно этого протокола на сайте должен быть установлен SSL-сертификат.

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

Следующий вопрос, который может у вас возникнуть, — а так ли необходимо устанавливать SSL-сертификат на свой сайт? Ответ один — да, это абсолютно необходимый в данный момент элемент сайта.

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

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

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

Начнем с первого критерия. Существует несколько компаний, которые выпускают сертификаты, мы остановимся на одних из самых известных на данный момент — это Sectigo и Let’s Encrypt.

Let’s Encrypt завоевал популярность за счет своего бесплатного распространения. А Sectigo выпускает несколько видов платных SSL-сертификатов. На примере сертификатов от Sectigo мы рассмотрим, какие виды бывают у SSL-сертификатов:

  • Sectigo Positive SSL — это самый базовый и недорогой вариант SSL-сертификата. Поэтому он является и самым распространенным. К тому же этот сертификат наиболее легко оформить с точки зрения документов — пользователю нужно лишь подтвердить владение доменом, другие документы предоставлять не требуется. По времени процесс оформления сертификата тоже довольно быстрый — если вы захотите установить Sectigo Positive SSL, вам понадобится всего несколько часов.
  • Sectigo Postitive Wildcard SSL — сертификат, который можно установить не только на сам домен, но и все поддомены этого адреса. Это намного выгоднее и удобнее, чем покупать для каждого поддомена отдельный сертификат.
  • Sectigo EV SSL — сертификат с расширенной проверкой. От предыдущих вариантов отличается тем, что при его заказе происходит проверка и подтверждение владельца сайта (компании или юридического лица), этим занимаются центры сертификации, и поэтому на выпуск этого сертификата требуется больше времени — несколько дней. Именно такой вид сертификата стоит на тех сайтах, где вы видите название компании перед адресом сайта.

Можно ли взломать сайт с SSL-сертификатом?

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

Чем опасны сертификаты?

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

В целом можно ответить, то нет, SSL-сертификат — это большой плюс сайту, можно даже сказать, что необходимость. Однако есть один нюанс, с которым вы можете столкнуться после его установки, — это проблема смешанного содержимого (или “mixed content”).

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

Если вы столкнулись с такой проблемой и не обладаете какими-либо знаниями в редактировании кода, то наилучшим решением будет обратиться к специалисту. Он проанализирует сайт и поможет вам решить эту проблему. Часто проблема заключается в том, что на сайте остались ссылки, ведущие на небезопасный протокол (“http://”) — и тогда необходимо либо изменить эти ссылки на относительные, либо на “https://”.

Где можно получить SSL-сертификат?

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

Если вы уже являетесь нашим клиентом, то можете оформить заказ прямо в своей панели управления.

А если после прочтения статьи у вас все еще остались какие-либо вопросы — обратитесь в нашу службу поддержки по бесплатному телефону 8 (800) 333-1081, через онлайн-чат на сайте или напишите на info@timeweb.ru.

Анализ SSL/TLS трафика в Wireshark

Как скрыть от посторонних конфиденциальную информацию?
Самое простое – зашифровать.
В Интернет и Интранет-сетях шифрацией данных управляет протокол SSL/TLS.
Солдат спит, служба идет.
Однако иногда возникает необходимость выполнить обратное – расшифровать перехваченный трафик.
Это может потребоваться как для отладки работы приложений, так и для проверки подозрительной сетевой активности.
Или в целях изучения работы SSL/TLS (очевидные, вредоносные цели не обсуждаются).
Как и при каких условиях можно расшифровать дамп SSL/TLS трафика в Wireshark?
Попробуем разобраться.
Разобраться с расшифровкой будет гораздо проще, если есть общие представления о принципах работы протокола SSL/TLS. Рассмотрим упрощённый вариант функционирования SSL/TLS, выделив в нем только самые важные для нас моменты.
Обычно началу обмена шифрованными данными, в SSL/TLS предшествует процесс установки соединения, рукопожатие (SSL handshake).
на хабре есть статья, подробно описывающая процесс установки SSL/TLS соединения (Первые несколько миллисекунд HTTPS соединения) thevar1able
На этом этапе помимо аутентификации и других действий две стороны (приложения) согласуют общий сеансовый ключ (симметричный). После согласования ключ используется приложениями для шифрации и расшифровки передаваемых между ними данных.
Однако как стороны согласуют одинаковый сеансовый ключ, общаясь по незащищенным каналам связи?
Для этого существуют различные алгоритмы. Наиболее часто используемые в Интернет – это RSA (самый популярный) и эфемерный Диффи-Хеллмана (DHE/ECDHE).
В момент установки SSL/TLS соединения алгоритм согласования сеансовых ключей выбирает сервер.
Выбор происходит из списка алгоритмов, поддерживаемых клиентом, которые он передает на сервер.
Ниже на диаграмме показан процесс согласования сеансовых ключей в случаях RSA и DHE/ECDHE, а также информация, которую видит сниффер (Wireshark) в перехваченном SSL/TLS трафике.
В первом случае (согласование ключей RSA) в момент установки соединения клиент генерирует случайное число, предварительный секрет (pre-master secret). Шифрует его открытым ключом, полученным в сертификате от сервера.
Отправляет в зашифрованном виде на сервер. Сервер расшифровывает предварительный секрет своим секретным ключом. Далее обе стороны, обладая одинаковым предварительным секретом, конвертируют его в главный и уже из него создают общий сеансовый ключ.
В ассиметричных алгоритмах шифрования (RSA) данные, зашифрованные открытым ключом, могут быть расшифрованы только секретным. При этом, открытый и секретный ключи должны быть связаны между собой определенным математическим образом, являются ключевой парой.
Во втором случае (согласование ключей DHE/ECDHE) все работает немного по-другому.
В момент установки нового соединения клиент и сервер генерируют пару случайных эфемерных (временных) ключей Диффи-Хеллмана.
Пара состоит из открытого и секретного ключей. Стороны обмениваются открытыми ключами.
Далее клиент и сервер, используя свой закрытый и полученный открытый ключи, создают предварительный секрет, главный секрет и общий сеансовый ключ.
В данном алгоритме постоянный секретный ключ сервера (RSA/DSA/ECDSA) в шифрации не участвует и используется только для подписи открытых DH-ключей. Описание очень общее, есть подробная информация в статье на хабре (Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчик) zavg.
Теперь возможно стало немного понятней.
Если клиент и сервер при согласовании сеансовых ключей используют алгоритм RSA, то перехваченный между ними трафик всегда можно расшифровать, имея секретный ключ сервера.
Дело в том, что в момент установки SSL/TLS-соединения клиент пересылает серверу зашифрованное значение предварительного секрета.
Предварительный секрет дешифруется секретным ключом сервера, далее вычисляется сеансовый ключ.
Данные расшифровываются полученным сеансовым ключом.
В случае использования алгоритма DHE/ECDHE и обладая секретным ключом сервера, расшифровать данные SSL/TLS трафика уже не получится.
В момент установки соединения передаются только открытые значения DH-ключей.
Секретные DH-ключи, необходимые для вычисления сеансовых, находятся в оперативной памяти клиента и сервера и после завершения соединения уничтожаются.
Эфемерные алгоритмы согласования ключей Диффи-Хеллмана (DHE/ECDHE) поддерживают Perfect Forward Secrecy (PFS).
Есть конечно другой, альтернативный вариант.
Подходит для расшифровки SSL/TLS-трафика без секретного ключа сервера, а также если используются алгоритмы DHE/ECDHE, RSA и другие.
В момент установки SSL/TLS-соединения в оперативной памяти клиента и сервера присутствуют открытые значения секретов, предварительного и главного.
Если успеть вытащить секреты из памяти и сохранить на диск, то в дальнейшем их также можно использовать для расшифровки данных.
Конечно, это не всегда просто сделать и не позволяет расшифровать трафик, перехваченный когда-либо ранее.
А теперь посмотрим, как на практике, обладая секретным ключом сервера или значениями секретов сессий, можно расшифровать SSL/TLS-трафик в Wireshark.

Wireshark + cекретный ключ сервера

Собственно, тут все относительно просто.
Загружаем в Wireshark дамп SSL/TLS-трафика обмена клиента с сервером, подключаем секретный ключ сервера и расшифровываем.
Конечно, предварительно стоит проверить, что клиент и сервер для согласования сеансовых ключей использовали алгоритм RSA.
Для этого находим инициализацию SSL/TLS-соединения (фильтр «ssl.handshake»).

Проверяем, что сервер в сообщении Server Hello в Cipher Suite указывает алгоритм RSA.
В ответном сообщении клиента (Client Key Exchange) присутствует зашифрованное значение предварительного секрета сессии (Encrypted PreMaster).
Выполняем настройки Wireshark.
В меню Edit —> Preferences слева раскрываем ветку со списком протоколов (Protocols) и выбираем SSL.
Проверяем установку флага «Reassemble SSL records spanning multiple TCP segments».
В поле «SSL debug file» указываем путь к логу с отладочной информацией (фиксируются результаты дешифрации, может пригодиться при разборе возникших проблем).
В поле «RSA keys list» жмем кнопку Edit.
В появившемся окне жмем кнопку New и заполняем поля:
• IP Address – IP-адрес SSL-сервера в IPv4 или IPv6-формате
• Port – номер порта SSL-сервера (для https обычно 443)
• Protocol – название протокола, использующего шифрацию SSL (например, http). Если не известен, указываем data
• Key File – путь к файлу секретного ключа сервера (файл формата PEM или PKCS#12)
• Password – заполняется, только если секретный ключ PKCS#12 и защищен паролем
Подтверждаем выполненные настройки и наслаждаемся просмотром расшифрованного трафика.
Для удобства через фильтр выводим только трафик прикладного уровня, например, http.
Также открытая информация доступна на закладке «Decrypted SSL Data», в нижней части окна.
Или выбираем любой пакет из SSL/TLS-сессии, нажимаем правую клавишу мыши, затем в списке – «Follow SSL Stream».
Получаем поток расшифрованных данных из выбранного соединения.

Wireshark + cекреты сессий

Кроме секретного ключа сервера, для расшифровки данных в Wireshark могут использоваться известные значения секретов сессий.
Хорошая возможность для тех, у кого нет секретного ключа сервера или если сервер выбирает алгоритм согласования сеансовых ключей с поддержкой PFS (DHE/ECDHE).
Где и как можно достать секреты сессий?

  1. Wireshark поддерживает экспорт предварительных секретов из загруженного дампа SSL/TLS-трафика.
    Wireshark, меню Files -> Export SSL Session Keys
    Конечно, перед этим трафик должен быть расшифрован секретным ключом сервера.
    Очень важная функциональность.
    Дело в том, что Wireshark не умеет сохранять трафик в расшифрованном виде.
    Иногда есть необходимость передать расшифрованный трафик кому-то еще, не компрометируя секретный ключ сервера.
    Для решения этой проблемы можно, как обычно, расшифровать трафик секретным ключом сервера и экспортировать из него все секреты SSL/TLS -сессий в отдельный файл.
    После этого становится возможным повторно расшифровать трафик, используя только файл с секретами.
  2. В некоторых приложениях существует встроенная функциональность, позволяющая сохранять секреты на диск.
    Яркий пример таких приложений – это браузеры Chrome и FireFox.
    Оба в своей работе используют криптографический модуль NSS, разрешающий логирование секретов в файл.
    Формат лога приведён ниже и соответствует первым двум вариантам.
    Более подробное описание функциональности есть в статье на хабре (Как легко расшифровать TLS-трафик от браузера в Wireshark) ValdikSS.
    В Java-программах секреты могут быть получены из SSL дебаг лога (Дешифрация TLS трафика Java приложений с помощью логов) Toparvion.
    Или сразу в формате Wireshark через jSSLKeyLog (Java Agent Library to log SSL session keys to a file for Wireshark)
  3. Другие варианты.
    Используя сторонние утилиты, перехватывать секреты сессий в оперативной памяти клиента или сервера.

А теперь – о том, как и в каком виде секреты загружаются в Wireshark.
Значения секретов сессий указываются построчно в обычном текстовом файле в определенном формате.
Существует три возможных формата строк:

  1. Для SSL/TLS-сессий с алгоритмом согласования сеансовых ключей RSA
    RSA <hex encrypted pre-master secret> <hex pre-master secret>
    <hex encrypted pre-master secret> — зашифрованное значение предварительного секрета сессии (поле Encrypted Premaster в сообщение ClientKeyExchange)
    <hex pre-master secret> — расшифрованное значение предварительного секрета
  2. Для SSL/TLS-сессий с алгоритмом согласования сеансовых ключей DHE/ECDHE
    CLIENT_RANDOM <hex client_random> <hex master secret>
    <hex client_random> — случайное число клиента (Random в сообщение Client Hello)
    <hex master secret> — значение главного секрета сессии
  3. Поддержка вывода Master-Key в «openssl s_client»
    RSA Session-ID:<hex session id> Master-Key:<hex master secret>
    <hex session id> — идентификатор сессии (поле Session ID из Server Hello или Session Ticket из Client Hello)
    <hex master secret> — значение главного секрета сессии

И теперь подключаем файл с секретами в Wireshark и дешифруем SSL/TLS-трафик.
Настройки Wireshark аналогичны указанным в предыдущем разделе.
За исключением того, что в настройках протокола SSL в «RSA keys list» не нужно ничего указывать (параметры SSL-сервера и его секретный ключ). Только в поле «(Pre)-Master-Secret log filename» путь к файлу с секретами.
Подтверждаем настройки и смотрим расшифрованный трафик.

Надеюсь, представленная информация окажется интересной всем,
кто планирует или уже занимается анализом SSL/TLS-трафика в Wireshark.
Все ссылки по теме:
Wireshark — приручение акулы PENTESTIT
Что такое TLS babayota_kun
Первые несколько миллисекунд HTTPS соединения thevar1able
Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчик zavg
Как легко расшифровать TLS-трафик от браузера в Wireshark ValdikSS
Дешифрация TLS трафика Java приложений с помощью логов Toparvion

Протокол SSL

SSL — это открытый криптографический протокол (Secure Sockets Layer protocol, протокол защищенных сокетов), разработанный в 1996 году компанией Netscape для передачи зашифрованной информации по открытым каналам, обеспечивая надежный, защищенный обмен данными между двумя приложениями, работающими удаленно. Для работы протокол использует ассиметричную криптосистему с открытым ключом, разработанную компанией RSA Data Security.

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

В многоуровневой модели OSI протокол SSL располагается между протоколом транспортного уровня (например, TCP), и протоколом прикладного уровня (чаще всего HTTP).

Протокол SSL имеет два уровня: протокол записей (SSL Record Protocol) и протокол диалога (SSL Handshake Protocol). Нижний уровень SSL — SSL Record Protocol располагается поверх транспортного протокола (например, TCP). Верхний уровень — SSL Handshake Protocol позволяет серверу и клиенту идентифицировать друг друга и согласовывать алгоритм шифрования и криптографические ключи, до начала обмена данными.

В протоколе SSL реализована возможность два типа идентификации (или аутентификации):

  • идентификация на стороне клиента;
  • идентификация на стороне сервера.

Серверная сторона аутентифицируется всегда, в то время как клиентская — аутентифицируется опционно.

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

SSL-аутентификация клиента позволяет серверу проверить личность пользователя. Используется в основном в финансовых системах.

При установлении соединения по SSL клиент и сервер обмениваются приветственными сообщениями (hello message). Кроме всего прочего приветственное сообщение устанавливает четыре основных параметра: версия протокола, идентификатор сессии, способ шифрования, метод компрессии, а также, два специально сгенерированных случайных числа; и сервер, и клиент, генерируют такие числа независимо друг от друга, а затем, просто обмениваются ими друг с другом.

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

Надежность соединения обеспечивается контролем целостности сообщений с помощью зашифрованного кода целостности (MAC). Для вычисления кодов МАС используются безопасные хэш-функции (например, безопасный хэш-алгоритм , MD5 и т.д.).

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

Версии SSL:

  • SSL v2.0 — первый реализованный протокол SSL
  • SSL v3.0 — ревизия протокола с целью предотвращения специфичных атак, добавление не-RSA шиф­ров и цепей сертификатов
  • TLS v1.Х — ревизия протокола SSL v3.0. Уровень MAC обновлен до HMAC. Добавлены дополнение блоков для блочных шифров, стандартизован порядок сообщений, расширены предупреди­тельные сообщения.

В настоящее время на смену SSL v3.0 пришел протокол TLS (Transport Layer Security), но она до сих пор используется во многих современных браузерах (Chrome, Firefox) и веб-серверах в целях обратной совместимости. По некоторым оценкам, через SSL 3.0 проходит около 1% всего интернет-трафика.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *