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

Перевод А. В. Южанинова citrin@citrin.ru. Оригинал статьи был опубликован на http://www.pseudonym.org/ssl/ssl_intro.html

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

Протокол SSL (Secure Sockets Layer protocol, протокол защищенных сокетов) \SSL3] предоставляет способ для аутентификации, контроля целостности, и конфиденциальности при использовании Web.

Данный документ содержит введение в концепцию SSL для тех, кто знаком с работой Web, HTTP, Web серверов, но не является специалистом по информационной безопасности. Он не предназначен быть исчерпывающим руководством по протоколу SSL, в нем так же нет описания определенных серверов или техник управления сертификатами. В нем так же не рассмотрены правовые аспекты: патенты и экспортные и импортные ограничения ¹⁾. Цель этого документа и статьи OpenSSL Certificate Cookbook дать начальную точку для дальнейшего изучения тем, кто хочет понять, как работает поддержка SSL на серверах.

Для понимания SSL необходимо понимать, что такое алгоритмы шифрования, хэш-функции и цифровые подписи. Эти вопросы хорошо раскрыты в книге «Прикладная криптография» \Schneier], и являются основой для обеспечения конфиденциальности, контроля целостности и аутентификации.

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

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

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

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

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

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

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

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

Хотя Алиса может послать банку секретное сообщение, подписать его, и быть уверенной, что оно не будет изменено, ей нужно быть уверенной, что открытый ключ в действительности принадлежит банку. Банк тоже должен быть уверенным в том, что цифровая подпись действительно принадлежит Алисе. Если каждый имеет сертификат, в котором сказано кто его владелец, содержится открытый ключ и все это подписано доверенной организацией, то они могут полагать, что они связываются действительно с теми, с кем предполагалось. Такая доверенная организация называется центром сертификации (Certificate Authority, CA), и сертификаты используются для аутентификации.

Содержимое сертификата:

Отличительное имя используется для идентификации в определенном контексте (например, человек может иметь личный сертификат и сертификат как сотрудник фирмы). Отличительные имена определены в стандарте X.509 \Kaufman], в котором определены имена, их аббревиатуры и требования к содержанию. Центр сертификации может определить правила, в которых определено какие поля обязательны, а какие нет. Могут так же определяться требования к содержимому полей. Например, браузер Netscape требует, чтоб в поле Common Name сертификата сервера было регулярное выражение для его доменного имени (например *.opengroup.org).

Отличительное имя:

Двоичный формат сертификата определяется с помощью нотации ASN.1 \ASN.1]. Эта нотация определяет, как содержимое сертификата преобразуется в двоичный вид. Двоичный формат сертификата определен с использованием правил DER, которые основаны на более общих правила BER. Двоичная форма может быть преобразована с использованием кодирования base64 в текст (ASCII) для тех случаев, когда нельзя использовать двоичный формат. Такой вид называется PEM (Privacy Enhanced Mail) и сертификат помещается между линиями:

  
  -----BEGIN CERTIFICATE-----
  
  -----END CERTIFICATE-----
  

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

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

Одна из проблем при использовании сертификатов - каждый должен быть кем нибудь подписан, если это не корневой сертификат. Т. к. это сертификат верхнего уровня, он не может быть выдан кем-то другим. В этом случае сертификат является «самоподписанным» (self-signed), поскольку субъект сертификации это орган, который его выдал. Поэтому, доверяя самоподписанным сертификатом нужно быть особенно осторожным. Мы можем доверять им обычно потому, что открытые ключи корневых центров широко известны. Клиенты и сервера настроены доверять им по умолчанию.

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

Организация центра сертификации это ответственность, требующая объединения административных, управленческих и технических систем. Центр сертификации не только выдает сертификаты, но и управляет ими. Это значит, он должен определять сроки действия сертификатов, продлять их и поддерживать списки выданных сертификатов, которые недействительны (certificate revocation lists, CRL). Если Алиса работает в компании и имеет сертификат как сотрудник, то когда она увольняется, сертификат должен быть отозван. Сертификат может быть широко распространен, и нельзя в нем самом указать, что он был отозван. При проверке действительности сертификата необходимо связаться с центром сертификации, выдавшим этот сертификат для того, чтобы проверить, не был ли он отозван, но часто эту часть процесса нужно выполнять вручную. В системах, где отзывы сертификатов имеют значение, необходимо убедиться, что список отозванных сертификатов проверяется.

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

Протокол SSL (Secure Sockets Layer protocol, протокол защищенных сокетов) - протокол, который может быть помещен в многоуровневой модели протоколов между протоколом обеспечивающим надежное соединение (например, TCP) и прикладным уровнем (например, HTTP). Он предоставляет безопасный канал между клиентам и сервером, предоставляя возможность взаимной аутентификации, использования цифровых подписей для обеспечения целостности и шифрования для конфиденциальности.

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

Существует несколько версий протокола SSL.

Проблемная группа проектирования Internet (Internet Engineering Task Force, IETF) работает над стандартом TLS (Transaction Layer Security - протокол защиты транспортного уровня).

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

Установка сеанса начинается с работы протокола квитирования (handshake sequence) между клиентом и сервером. Эта последовательность может зависеть от того, настроен ли сервер предоставлять сертификат, и требует ли он наличие сертификата у клиента. Возможно так же, для согласования параметров алгоритма шифрования потребуются дополнительные шаги. В этом документе описывается типичный сценарий, а остальные возможности SSL не рассматриваются.

Протокол квитирования используется клиентом и сервером для:

1. Согласования параметров шифрования (Cipher Suite), которые будут использован при передаче данных
2. Выработки и передачи сеансового ключа между клиентом и сервером
3. Необязательной аутентификации сервера клиентом.
4. Необязательной аутентификации клиента сервером.

Рис. 1. Упрощенный порядок квитирования (Handshake)

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

1. Метода обмена ключами
2. Симметричного алгоритма шифрования для передачи данных
3. Функции хеширования для создания MAC (Message Authentication Code - код аутентичности сообщения).

Метод обмена ключами определяет, как клиент и сервер согласуют общий ключ для симметричного алгоритма шифрования. The key exchange method defines how the shared secret symmetric cryptography В SSL 2.0 для обмена ключей используется RSA. В SSL 3.0 возможен выбор между RSA, при использовании сертификатов, и методом обмена ключами по Диффи-Хеллману (Diffie-Hellman) для обмена ключами без сертификатов и без предыдущей связи между клиентом и сервером \Kaufman].

Выбор метода обмена ключами включает решение использовать или не использовать цифровые подписи при обмене ключами, и какой способ цифровой подписи использовать. Подпись закрытым ключом защищает от атак человек по середине (man-in-the-middle-attack) во время обмена информацией, используемой для выработки общего ключа.

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

1. Нет шифрования
2. Поточное шифрование
   1. RC4 с ключом 40 бит
   2. RC4 с ключом 128 бит
3. Алгоритмы используемые в режиме CBC
   1. RC2 с ключом 40 бит
   2. DES40, DES, 3DES_EDE.
   3. Idea
   4. Fortezza

Режим CBC (Cipher Block Chaining - сцепление блоков шифра), предыдущий зашифрованный блок используется при шифровании текущего блока. DES - Data Encryption Standard \Schneier, ch12], имеет множество вариантов (включая DES40 and 3DES_EDE). Idea (один из наиболее стойких алгоритмов) и RC2 являются собственностью компании RSA \Schneier, ch13].

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

1. Без хеширования
2. MD5, хеш 128 длиной бит
3. Secure Hash Algorithm (SHA), хеш 160 бит

SHA был разработан для использования совместно с DSS (Digital Signature Standard - стандарт цифровой подписи).

Протокол квитирования предоставляет множество возможностей, но наиболее распространенная последовательность включает обмен сертификатами и обмен ключами по методу Деффи-Хеллмана. В других случаях порядок квитирования отличается, как описано в спецификации SSL. Последовательность квитирования использует три протокола, протокол квитирования SSL (SSL Handshake Protocol) для открытия сеанса между клиентом и сервером, протокол согласования параметров шифрования (SSL Change Cipher Spec protocol) для согласования набора криптоалгоритмов и их параметров и протокол извещения (SSL Alert Protocol) для обмена сообщениями об ошибках между клиентом и сервером. Эти протоколы инкапсулированы в протокол записи SSL (SSL Record Protocol) как данные прикладного уровня. Инкапсулированный протокол передается как данные нижележащим протоколом, которые не анализирует эти данные. Инкапсулированный протокол ничего не знает о нижних протоколах.

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

Рис. 2. Стек протоколов SSL

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

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

SSL использует хэш-функции сообщения и порядковые номера для вычисления кодов аутентичности сообщения (MAC, Message Authentication Code), которые шифруются, что предотвращает атаки повтора. Блоки протокола записи, сжатые блоки и зашифрованные блоки содержат идентификатор исходного протокола, длину сообщения и данные.

Одно из распространенных применений SSL - защита данных передаваемых по HTTP между клиентом и веб-сервером. Безопасный вариант URL начинается с «https», вместо «http», и используется другой порт (по умолчанию 443)/ Браузер хранит клиентские сертификаты и закрытые ключи, и показывает индикатор защищенного соединения, когда оно используется.

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

Есть два известных пакета для работы с несимметричным алгоритмом RSA:

• RSARef Образец реализации RSA, неподдерживаемый исходный код библиотеки, может быть использован в бесплатных и некоммерческих приложениях. Компания Consensus Development Corp. продавала лицензии на коммерческое использование, но сейчас это уже не так.
• BSAFE 3.0 Коммерческая реализация RSARef.

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

• SSLRef образец реализации SSL 3.0 от Netscape Communications Corp.
• SSLPlus Коммерческий пакет с исходным пакетом от Consensus Development Corp., улученный SSLRef 3.0. Для использования нужен BSAFE 3.0 (from RSA).
• SSLava Реализация SSL 3.0 на языке Java от Phaos Technology.
• OpenSSL OpenSSL-0.9.4 (OpenSSL-0.9.4.tar.gz) свободная, не коммерческая реализация SSL 2.0 и SSL 3.0 и TLS 2.0. Включает реализацию несимметричных алгоритмов, которая может быть использована за приделами США. В Штатах из-за патентных ограничений необходимо использовать RSARef или BSAFE3.0. SSLeay предоставляет недорогую возможность для использования SSL. \OpenSSL FAQ]

Taher Elgamal, Jeff Treuhaft, Frank Chen, Securing Communications on the Intranet and Over the Internet, Netscape Communications Corporation, July 1996. http://www.go-digital.net/whitepapers/securecomm.html

Burton S. Kaliski Jr., An Overview of the PKCS Standards, An RSA Laboratories Technical Note, Revised November 1, 1993. http://www.rsa.com/rsalabs/pubs/PKCS/

Charlie Kaufman, Radia Perlman, Mike Speciner, Network Security: PRIVATE Communication in a PUBLIC world, Prentice Hall, 1995.

Crypto Law Survey, Bert-Jaap Koops, http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm Version 8.2, May 1997.

SSL Resource Center, http://www.phaos.com/sslresource.html

Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, 1996. See http://www.counterpane.com/ for various materials by Bruce Schneier.

Burton S. Kaliski Jr., A Layman's Guide to a Subset of ASN.1, BER, and DER, An RSA Laboratories Technical Note, Revised November 1, 1993. http://www.rsa.com/rsalabs/pubs/PKCS/

Installing Certificates and Root Keys in Microsoft Internet Explorer 3.0 and IIS http://www.microsoft.com/intdev/security/csa/enroll.htm

http://www.netscape.com/eng/security/certs.html