Уровень защищенных сокетов

Протокол SSL был первоначально разработан Netscape для обеспечения безопасности данных, передаваемых и маршрутизируемых через уровни приложений HTTP, LDAP или POP3. SSL предназначен для использования TCP в качестве коммуникационного уровня для обеспечения надежного сквозного безопасного соединения с проверкой подлинности между двумя точками в сети (например, между клиентом службы и сервером). Несмотря на то, что этот SSL может использоваться для защиты данных при передаче в ситуациях, связанных с любой сетевой службой, он используется в основном в HTTP-серверах и клиентских приложениях. Сегодня почти каждый доступный HTTP-сервер может поддерживать сеанс SSL, в то время как браузеры IE или Netscape Navigator поставляются с клиентским программным обеспечением с поддержкой SSL.

Цели и архитектура SSL

Какие проблемы решает SSL? Основными задачами SSL являются:

• Аутентификация клиента и сервера по отношению друг к другу: протокол SSL поддерживает использование стандартных криптографических методов (шифрование с открытым ключом) для аутентификации взаимодействующих сторон друг с другом. Хотя наиболее частое применение заключается в аутентификации клиента службы на основе сертификата, SSL также может использовать те же методы для аутентификации клиента.
  
• Обеспечение целостности данных: во время сеанса данные не могут быть намеренно или непреднамеренно изменены.
  
• Защита конфиденциальности данных: данные при транспортировке между клиентом и сервером должны быть защищены от перехвата и доступны для чтения только предполагаемому получателю. Это предварительное условие необходимо как для данных, связанных с самим протоколом (защита трафика во время переговоров), так и для данных приложения, которые отправляются во время самого сеанса. На самом деле SSL — это не отдельный протокол, а скорее набор протоколов, которые можно дополнительно разделить на два уровня:

1. протокол для обеспечения безопасности и целостности данных: этот уровень состоит из протокола записи SSL,
   
2. протоколы, предназначенные для установления соединения SSL: на этом уровне используются три протокола: протокол рукопожатия SSL, протокол SSL ChangeCipher SpecP и протокол оповещения SSL.

Стек протоколов SSL показан на рисунке 2.

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

SSL-сеанс и соединение

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

• соединение: это логическая связь клиент/сервер, связанная с предоставлением соответствующего типа услуги. В терминах SSL это должно быть одноранговое соединение с двумя сетевыми узлами.
  
• сеанс: это ассоциация между клиентом и сервером, которая определяет набор параметров, таких как используемые алгоритмы, номер сеанса и т. д. Сеанс SSL создается протоколом рукопожатия, который позволяет совместно использовать параметры между соединениями, установленными между сервером и сервером. клиент и сеансы используются, чтобы избежать согласования новых параметров для каждого соединения.
  Это означает, что один сеанс используется несколькими SSL-соединениями между клиентом и сервером. Теоретически также может быть возможно, что несколько сеансов совместно используются одним соединением, но на практике эта функция не используется. Понятия сеанса SSL и соединения включают несколько параметров, которые используются для связи с поддержкой SSL между клиентом и сервером. Во время согласования протокола рукопожатия устанавливаются методы шифрования, а затем в рамках сеанса используется ряд параметров состояния сеанса. Состояние сеанса определяется следующими параметрами:
  
• идентификатор сеанса: это идентификатор, сгенерированный сервером для идентификации сеанса с выбранным клиентом,
  
• Сертификат узла: сертификат узла X.509,
  
• метод сжатия: метод, используемый для сжатия данных перед шифрованием,
  
• Спецификация алгоритма под названием CipherSpec: определяет алгоритм шифрования больших объемов данных (например, DES) и алгоритм хеширования (например, MD5), используемые во время сеанса.
  
• Главный секрет: 48-байтовые данные являются секретом, разделяемым между клиентом и сервером.
  
• «возобновляемый»: это флаг, указывающий, можно ли использовать сеанс для инициирования новых подключений.
  Согласно спецификации состояние SSL-соединения определяется следующими параметрами:
  
• Случайные сервер и клиент: случайные данные, генерируемые как клиентом, так и сервером для каждого соединения,
  
• Секрет MAC записи сервера: секретный ключ, используемый для данных, записываемых сервером,
  
• Секрет MAC записи клиента: секрет, используемый для данных, записанных клиентом,
  
• Ключ записи сервера: ключ массового шифрования для данных, зашифрованных сервером и расшифрованных клиентом.
  
• Ключ записи клиента: ключ массового шифрования для данных, зашифрованных клиентом и расшифрованных сервером.
  
• Порядковый номер: порядковые номера, поддерживаемые сервером отдельно для сообщений, переданных и полученных во время сеанса передачи данных.

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

Протокол записи SSL

Протокол записи SSL предполагает использование SSL безопасным способом и с гарантией целостности сообщения. С этой целью он используется протоколами SSL верхнего уровня. Цель протокола записи SSL состоит в том, чтобы принять сообщение приложения для передачи, фрагментировать данные, которые необходимо отправить, инкапсулировать их с соответствующими заголовками и создать объект, только что названный записью, который зашифрован и может быть перенаправлен для отправки под протокол TCP. Первым этапом подготовки передачи данных приложения является их фрагментация, т.е. разбиение потока данных, подлежащих передаче, на фрагменты данных размером 16 Кб (или меньше) с последующим процессом их преобразования в запись. Эти фрагменты данных могут быть дополнительно сжаты, хотя спецификация протокола SSL 3.0 не включает протокол сжатия, поэтому в настоящее время сжатие данных не используется.
В этот момент начинается создание записи для каждой порции данных путем добавления к ней заголовка, возможной информации для завершения требуемого размера данных и MAC. Заголовок записи, который добавляется к каждой порции данных, содержит две элементарные части информации, а именно длину записи и длину блока данных, добавленного к исходным данным.
На следующем шаге построенные данные записи состоят из следующих элементов:

• первичные данные,
  
• некоторое дополнение для завершения дейтаграммы по мере необходимости,
  
• значение МАК.

MAC отвечает за проверку целостности сообщения, включенного в передаваемую запись. Это результат хеш-функции, которая следует определенному хэш-алгоритму, например MD5 или SHA-1. MAC определяется в результате хэш-функции, которая получает следующие данные:
MAC = хеш-функция [секретный ключ, первичные данные, заполнение, порядковый номер].
Секретный ключ при создании MAC представляет собой либо секрет MAC записи клиента, либо секрет MAC записи сервера, соответственно, это зависит от того, какая сторона подготавливает пакет. После получения пакета принимающая сторона вычисляет собственное значение MAC и сравнивает его с полученным. Если два значения совпадают, это означает, что данные не были изменены во время передачи по сети. Длина полученного таким образом MAC зависит от метода, используемого для его вычисления. Далее данные плюс MAC шифруются с использованием предварительно заданного алгоритма симметричного шифрования, например DES или тройного DES. И данные, и MAC зашифрованы. Эти подготовленные данные прикрепляются со следующими полями заголовка:

• Тип содержимого: определяет, какая полезная нагрузка доставляется пакетом, чтобы определить, какие более высокие протоколы следует использовать для обработки данных, включенных в пакет. Возможные значения: change_cipher_spec, alert, handshake и application_data, которые относятся к соответствующим протоколам.
  
• Основная версия: устанавливает основную часть используемой версии протокола. Для SSL 3.0 значение равно 3,
  
• Второстепенная версия: устанавливает дополнительную часть используемой версии протокола. Для SSL 3.0 значение равно 0.

С добавлением полей процесс подготовки записи завершен. После этого запись отправляется в указанную точку. Весь процесс подготовки пакета к отправке показан на рисунке 3.

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

Протокол оповещения
Alert Protocol используется сторонами для передачи сеансовых сообщений, связанных с обменом данными и функционированием протокола. Каждое сообщение в протоколе оповещения состоит из двух байтов. Первый байт всегда принимает значение «предупреждение» (1) или «фатальный» (2), которое определяет серьезность отправленного сообщения. Отправка сообщения со статусом «фатальный» любой из сторон приведет к немедленному завершению сеанса SSL. Следующий байт сообщения содержит один из определенных кодов ошибок, которые могут возникнуть во время сеанса связи SSL.

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

Протокол рукопожатия
Протокол рукопожатия представляет собой наиболее сложную часть протокола SSL. Он используется для инициации сеанса между сервером и клиентом. В сообщении этого протокола согласовываются различные компоненты, такие как алгоритмы и ключи, используемые для шифрования данных. Благодаря этому протоколу можно аутентифицировать стороны друг друга и согласовывать между ними соответствующие параметры сеанса.
Процесс переговоров между клиентом и сервером показан на рисунке 4. Его можно разделить на 4 этапа, разделенных горизонтальными пунктирными линиями. На первом этапе должно быть инициировано логическое соединение между клиентом и сервером, после чего следует согласование параметров соединения. Клиент отправляет серверу сообщение client_hello, содержащее такие данные, как:

• Версия: максимальная версия SSL, поддерживаемая клиентом.
  
• Случайный: данные, состоящие из 32-битной метки времени и 28 байтов случайно сгенерированных данных. Эти данные используются для защиты сеанса обмена ключами между сторонами соединения.
  
• Идентификатор сеанса: число, определяющее идентификатор сеанса. Ненулевое значение этого поля указывает, что клиент хочет обновить параметры существующего соединения или установить новое соединение в этом сеансе. Нулевое значение в этом поле указывает на то, что клиент хочет установить новое соединение.
  
• CipherSuite: список алгоритмов шифрования и метода обмена ключами, поддерживаемых клиентом.
  Сервер в ответ на сообщение client_hello отправляет сообщение server_hello, содержащее тот же набор полей, что и сообщение клиента, размещая следующие данные:
  
• Версия: наименьший номер версии протокола SSL, поддерживаемый сервером.
  
• случайные данные: тот же способ, который используется клиентом, но генерируемые данные полностью независимы,
  
• идентификатор сеанса: если поле клиента было ненулевым, обратно отправляется то же значение; в противном случае поле идентификатора сеанса сервера содержит значение для нового сеанса,
  
• CipherSuite: сервер использует это поле для отправки единого набора протоколов, выбранных сервером из предложенных клиентом. Первый элемент этого поля — выбранный метод обмена криптографическими ключами между клиентом и сервером. Следующим элементом является спецификация алгоритмов шифрования и хеш-функций, которые будут использоваться в рамках инициируемого сеанса, а также всех конкретных параметров.

Набор алгоритмов шифрования и метод обмена ключами, отправленный в поле CipherSuite, устанавливает три компонента:

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

Сервер начинает следующую фазу переговоров, отправляя свой сертификат клиенту для аутентификации. Сообщение, отправляемое клиенту, содержит один или цепочку сертификатов X509. Они необходимы для аутентификации как сервера, так и пути сертификации к доверенному официальному лицу по сертификации органа по сертификации для сервера. Этот шаг необязателен и может быть пропущен, если согласованный метод обмена ключами не требует отправки сертификата (в случае анонимного метода Диффи-Хеллмана). В зависимости от согласованного метода обмена ключами сервер может отправить дополнительное сообщение server_key_exchange, которое, однако, не требуется в случае, когда был согласован фиксированный метод обмена ключами Диффи-Хеллмана или метод обмена ключами RSA. Более того, сервер может запросить сертификат у клиента. Последним шагом фазы 2 является сообщение server_done, которое не имеет параметров и отправляется сервером только для того, чтобы указать конец сообщений сервера. После отправки этого сообщения сервер ожидает ответа клиента. После получения сообщения клиент должен проверить сертификат сервера, данные проверки сертификата и путь, а также любые другие параметры, отправленные сервером в сообщении server_hello. Проверка клиента состоит из:

• Проверка даты проверки сертификата и сравнение с текущей датой, чтобы убедиться, что сертификат все еще действителен,
  
• проверка наличия удостоверяющего органа в списке доверенных удостоверяющих центров, которым владеет клиент. Если ЦС, выдавший сертификат сервера, не включен в список ЦС, клиент пытается проверить подпись ЦС. Если невозможно получить информацию о ЦС, клиент завершает процедуру идентификации, либо возвращая сигнал об ошибке, либо сообщая о проблеме пользователю для ее решения.
  
• Идентификация подлинности открытого ключа УЦ, выдавшего сертификат: если Удостоверяющий центр включен в список доверенных УЦ клиента, клиент сверяет открытый ключ УЦ, указанный в сертификате сервера, с открытым ключом, доступным из списка. Эта процедура проверяет подлинность сертифицирующего органа.
  
• проверка того, соответствует ли доменное имя, используемое в сертификате, имени сервера, указанному в сертификате сервера.

После успешного выполнения всех шагов сервер считается аутентифицированным. Если все параметры совпадают и сертификат сервера правильно проверен, клиент отправляет серверу одно или несколько сообщений. Далее следует сообщение client__key_exchange, которое необходимо отправить для доставки ключей. Содержание этого сообщения зависит от согласованного метода обмена ключами. Кроме того, по запросу сервера сертификат клиента отправляется вместе с сообщением, разрешающим проверку сертификата. Эта процедура завершает Фазу 3 переговоров.
Фаза 4 заключается в подтверждении полученных сообщений и проверке правильности ожидающих обработки данных. Клиент отправляет сообщение change_cipher_spec (в соответствии с ожидающей спецификацией SSL ChangeCipher Spec), а затем устанавливает ожидающий набор параметров алгоритма и ключей в текущий набор того же самого. Затем клиент отправляет готовое сообщение, которое сначала защищается только что согласованными алгоритмами, ключами и секретами. Это необходимо для подтверждения правильности согласованных параметров и данных. Сервер в ответ клиенту отправляет такую же последовательность сообщений. Если готовое сообщение правильно прочитано любой из сторон, это подтверждает правильность переданных данных, согласованных алгоритмов и сеансового ключа. Это указывает на то, что сеанс завершен и возможна передача данных приложения между сервером и клиентом через SSL. В этот момент сеанс TCP между клиентом и сервером закрывается, однако состояние сеанса сохраняется, что позволяет возобновить связь в рамках сеанса с использованием сохраненных параметров.
Стоит отметить, что оба этапа 2 и 3 используются обеими сторонами для проверки подлинности сертификата сервера и, возможно, сертификата клиента на этапе рукопожатия. Если сервер не может быть успешно аутентифицирован клиентом на основе доставленного сертификата, рукопожатие прекращается, и клиент генерирует сообщение об ошибке. То же самое произойдет на сервере, если подлинность сертификата клиента не может быть подтверждена.
Рисунок 4. Установление сеанса SSL между клиентом и сервером (красный цвет — необязательные сообщения).

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

SSL на практике

В чем причина этих сложных вещей, связанных с SSL-соединением? SSL используется во многих службах, но в основном SSL защищает канал связи HTTP через Интернет, и поэтому протокол SSL довольно часто рассматривается как связанный только со страницами WWW. Как уже упоминалось, протокол SSL можно использовать для защиты передачи для любой службы TCP/IP. Помимо доступа к WWW, второе наиболее вероятное применение этого протокола связано с отправкой и получением электронной почты.
Что касается приложений Windows NT/2000/XP, SSL практически используется в системе серверных служб HTTP и SMTP, работающих совместно с IIS. Эти серверы позволяют генерировать соответствующий запрос с использованием собственного сертификата пользователя (используя службы сертификации Windows 2000 Server) или путем получения сертификата от одного из доверенных центров сертификации, таких как VeriSign (www.verisgn.com) или Thawte (www.thawte)..com). Описание установки сертификата для WWW-сервера, работающего в связке с IIS, см. на странице www.faq.net.pl/article.asp?id=237. Таким же образом, как и для WWW-сервера, можно получить и установить сертификат на SMTP-сервер, поставляемый вместе с IIS или доступный в Exchange 2000. Возможное применение SSL для поддержки других служб зависит от возможности настройки таких соединение сервером.

Портовая служба
HTTPS 443
LDAP 646
ННТП 563
SMTP 465
POP3 995
TSL: получение большего от SSL

В 1996 году рабочая группа IETF попыталась разработать стандартизированный безопасный метод Интернета для связи через Интернет. Они приняли SSL 3.0 в качестве отправной точки и в 1999 году выпустили документ RFC 2246, определяющий новый протокол Transport Layer Security (TLS) в его версии 1.0. Основная цель, поставленная целевой группой для достижения с помощью TLS, была аналогична цели, связанной со стандартами SSL, а именно: обеспечить функции безопасности и целостности данных на транспортном уровне между двумя веб-приложениями. Более того, разработчики добавили в TSL некоторые дополнительные возможности:

• Совместимость: отношение TLS к созданию приложений с поддержкой TSL и обмену параметрами TLS любой стороной, при этом другой стороне не нужно знать подробности реализации TLS.
  
• Расширяемость: TLS рассматривается как средство обеспечения основы для простых будущих расширений, которые будут встроены в новые криптографические технологии, основанные, однако, на тех же протоколах, несмотря на изменения, внесенные в криптографические протоколы.
  И TLS, и его предшественник SSL состоят из двух основных уровней протокола:
  
• Протокол записи TLS: он выполняет ту же роль, что и протокол записи SSL, а именно используется для обеспечения безопасности и целостности данных, отправляемых во время сеанса клиент/сервер,
  
• Протокол рукопожатия TLS: для согласования параметров подключения; он выполняет ту же функцию, что и ранее описанное SSL-рукопожатие.

TLS был разработан как основа, используемая протоколами прикладного уровня, которые накладываются поверх протокола TLS. Однако спецификация, представленная в RFC 2246, не определяет, как эти протоколы верхнего уровня должны использовать TLS для защиты передачи. Целевая группа TLS решила решить эту проблему с помощью разработчиков приложений и протоколов. Помимо разработки самой спецификации протокола, IETF разработал два дополнительных документа RFC:

• RFC 2817 «Обновление до TLS в HTTP/1.1»,
  
• RFC 2818 «HTTP через TLS».

Оба документа иллюстрируют реализацию TLS с использованием протокола HTTP для замены использовавшегося до сих пор метода Secure Sockets Layer. Они демонстрируют, среди прочего, метод использования защищенного HTTP-соединения TLS без необходимости использования какого-либо дополнительного порта для зашифрованных соединений, в отличие от протокола SSL. Зашифрованное соединение TLS инициируется с использованием стандартного порта HTTP. Документ RFC 2487 «Расширение службы SMTP для безопасного SMTP через TLS», определяющий способ установки безопасного SMTP-соединения с использованием стандартного порта и расширений протокола, является следующим примером спецификации приложения для TLS.
Сегодня TLS поддерживается частями как серверного, так и клиентского программного обеспечения. Браузер Internet Explorer, например, поддерживает SSL. Несмотря на это, в настоящее время SSL является наиболее часто используемым методом обеспечения безопасности интернет-коммуникаций, однако прогнозируется, что он будет заменен TLS, который станет признанным стандартом безопасности для услуг передачи данных через Интернет.

Спецификации протокола см. также:
http://www.netscape.com/eng/security/SSL_2.html — Спецификация SSL 2.0,
http://www.netscape.com/eng/ssl3/3-SPEC.HTM — Спецификация SSL 3.0,
http://www.ietf.org/html.charters/tls-charter.html,
http://www.ietf.org/rfc.html — документы RFC.
http://www.netscape.com/eng/security/SSL_2.html — Спецификация SSL 2.0
http://www.netscape.com/eng/ssl3/3-SPEC.HTM — Спецификация SSL 3.0