SSL/TLS Сильное шифрование: Введение

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

Криптографические методы

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

Криптографические алгоритмы

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

Существуют две категории криптографических алгоритмов: традиционные и с открытым ключом.

Традиционная криптография

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

Криптография с открытым ключом

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

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

Хеширование сообщений

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

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

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

Один из способов безопасной передачи хеша — включить его в цифровую подпись.

Цифровые подписи

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

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

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

Сертификаты

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

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

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

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

Таблица 1: Информация о сертификате

Различительное имя используется для предоставления идентификации в конкретном контексте — например, у отдельного лица может быть личный сертификат, а также сертификат, подтверждающий его как сотрудника. Различительные имена определяются стандартом X.509 [X509], который определяет поля, имена полей и аббревиатуры, используемые для обозначения полей (см. таблицу 2).

Таблица 2: Информация о различительном имени

Центр сертификации может определить политику, определяющую, какие поля имени с различительным именем являются необязательными, а какие — обязательными. Он также может установить требования к содержимому полей, как и пользователи сертификатов. Например, браузер Netscape требует, чтобы общее имя для сертификата, представляющего сервер, соответствовало шаблону с подстановкой для доменного имени этого сервера, например, *.snakeoil.com.

Бинарный формат сертификата определён с помощью обозначения ASN.1 [ASN1] [PKCS]. Это обозначение определяет, как указать содержимое, а правила кодирования определяют, как эта информация преобразуется в бинарную форму. Бинарное кодирование сертификата определяется с помощью правил кодирования с различительным кодированием (DER), которые основаны на более общем правиле кодирования с базовым кодированием (BER). Для тех передач, которые не могут обрабатывать двоичный код, двоичный вид может быть преобразован в ASCII-вид с помощью кодирования Base64 [MIME]. При размещении между начальными и конечными разделительными строками (как показано ниже), этот закодированный вариант называется сертификатом в кодировании PEM ("Privacy Enhanced Mail").

-----BEGIN CERTIFICATE-----
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
-----END CERTIFICATE-----

Центры сертификации

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

Цепочки сертификатов

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

Создание Корневого CA

Как отмечалось ранее, каждый сертификат требует, чтобы издатель подтвердил подлинность личности субъекта сертификата, вплоть до сертификационного центра высшего уровня (CA). Это представляет проблему: кто может поручиться за сертификат высшего уровня, у которого нет издателя? В этом уникальном случае сертификат «самоподписанный», поэтому издатель сертификата совпадает с субъектом. Браузеры предварительно настроены на доверие хорошо известным центрам сертификации, но важно проявлять особую осторожность при доверие к самоподписанному сертификату. Широкое опубликование открытого ключа корневым центром сертификации снижает риск доверия к этому ключу — было бы очевидно, если бы кто-то другой опубликовал ключ, утверждая, что он является данным центром сертификации.

Несколько компаний, таких как Thawte и VeriSign, зарекомендовали себя как центры сертификации. Эти компании предоставляют следующие услуги:

• Проверка запросов на сертификат
• Обработка запросов на сертификат
• Выдача и управление сертификатами

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

Управление сертификатами

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

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

Протокол защищенных сокетов (SSL)

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

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

Таблица 4: Версии протокола SSL

Существует несколько версий протокола SSL, как показано в Таблице 4. Как отмечалось, одним из преимуществ SSL 3.0 является добавление поддержки загрузки цепочки сертификатов. Эта функция позволяет серверу передать сертификат сервера вместе с сертификатами издателя браузеру. Загрузка цепочки также позволяет браузеру проверять сертификат сервера, даже если сертификаты центра сертификации не установлены для промежуточных издателей, поскольку они включены в цепочку сертификатов. SSL 3.0 является основой для стандартного протокола безопасности транспортного уровня [TLS], в настоящее время разрабатываемого рабочей группой по интернет-инженерии (IETF).

Установление сеанса

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

Рисунок 1: Упрощенная последовательность рукопожатия SSL

Ниже приведены элементы последовательности рукопожатия, используемые клиентом и сервером:

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

На первом шаге, «Согласовании набора шифров», клиент и сервер выбирают набор шифров, поддерживаемый обоими. Спецификация протокола SSL3.0 определяет 31 набор шифров. Набор шифров определяется следующими компонентами:

• Метод обмена ключами
• Шифр для передачи данных
• Функция хеширования для создания кода аутентификации сообщения (MAC)

Эти три элемента описаны в последующих разделах.

Метод обмена ключами

Метод обмена ключами определяет, как будет согласован общий секретный симметричный ключ, используемый для передачи данных приложения, клиентом и сервером. SSL 2.0 использует только обмен ключами RSA, в то время как SSL 3.0 поддерживает выбор алгоритмов обмена ключами, включая обмен ключами RSA (при использовании сертификатов) и обмен ключами Diffie-Hellman (для обмена ключами без сертификатов или без предварительного взаимодействия между клиентом и сервером).

Одним из переменных в выборе методов обмена ключами являются цифровые подписи — использовать их или нет, и если да, то какие подписи использовать. Подписание с помощью закрытого ключа защищает от атаки «человек посередине» во время обмена информацией, используемой для генерации общего ключа [AC96, с. 516].

Шифр для передачи данных

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

• Без шифрования
• Потоковые шифры
  • RC4 с ключами длиной 40 бит
  • RC4 с ключами длиной 128 бит
• Блочные шифры CBC
  • RC2 с ключом длиной 40 бит
  • DES с ключом длиной 40 бит
  • DES с ключом длиной 56 бит
  • Triple-DES с ключом длиной 168 бит
  • Idea (ключ длиной 128 бит)
  • Fortezza (ключ длиной 96 бит)

«CBC» относится к блочному шифрованию с цепочкой блоков, что означает, что часть ранее зашифрованного шифротекста используется при шифровании текущего блока. «DES» относится к стандарту шифрования данных [AC96, гл. 12], который имеет несколько вариантов (включая DES40 и 3DES_EDE). «Idea» в настоящее время является одним из лучших и криптографически наиболее сильных доступных алгоритмов, а «RC2» — это проприетарный алгоритм от RSA DSI [AC96, гл. 13].

Функция хеширования

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

• Без хеширования (пустой выбор)
• MD5, 128-битный хеш
• Алгоритм хеширования SHA-1, 160-битный хеш

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

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

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

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

Эти протоколы, а также данные протокола приложения, инкапсулированы в протокол записи SSL, как показано на рисунке 2. Инкапсулированный протокол передается как данные протоколом нижнего уровня, который не анализирует данные. Инкапсулированный протокол не имеет никакого знания о лежащем в основе протоколе.

Рисунок 2: Стек протоколов SSL

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

Передача данных

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

Рисунок 3: Протокол SSL Record

Защита HTTP-соединения

Одним из распространённых применений SSL является обеспечение безопасности веб-соединений HTTP между браузером и веб-сервером. Это не исключает использования небезопасного HTTP — защищённая версия (называемая HTTPS) идентична простому HTTP с использованием SSL, но использует схему URL https вместо http, и другой порт сервера (по умолчанию порт 443). Эта функциональность является значительной частью того, что mod_ssl предоставляет для веб-сервера Apache.

Ссылки

[AC96]

Брюс Шнайер, Прикладная криптография, 2-е издание, Wiley, 1996. Смотрите http://www.counterpane.com/ для различных других материалов Брюса Шнайера.

[ASN1]

Рекомендация ITU-T X.208, Спецификация абстрактной нотации синтаксиса один (ASN.1), последняя обновление 2008. Смотрите http://www.itu.int/ITU-T/asn1/.

[X509]

Рекомендация ITU-T X.509, Фреймворк аутентификации каталога. Для ссылок, см. http://en.wikipedia.org/wiki/X.509.

[PKCS]

Стандарты криптографии с открытым ключом (PKCS), Технические заметки RSA Laboratories, Смотрите http://www.rsasecurity.com/rsalabs/pkcs/.

[MIME]

Н. Фрид, Н. Борейнстейн, Многоцелевые расширения электронной почты Интернет (MIME) Часть первая: Формат сообщений Интернет, RFC2045. Смотрите, например, http://tools.ietf.org/html/rfc2045.

[SSL3]

Алан О. Фрайер, Филип Карлтон, Пол К. Кочер, Протокол SSL версии 3.0, 1996. Смотрите http://www.netscape.com/eng/ssl3/draft302.txt.

[TLS1]

Тим Дьеркс, Кристофер Аллен, Протокол TLS версии 1.0, 1999. Смотрите http://ietf.org/rfc/rfc2246.txt.

[TLS11]

Протокол TLS версии 1.1, 2006. Смотрите http://tools.ietf.org/html/rfc4346.

[TLS12]

Протокол TLS версии 1.2, 2008. Смотрите http://tools.ietf.org/html/rfc5246.