Надёжное шифрование 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 («почта с повышенной конфиденциальностью»).

-----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) верхнего уровня. Возникает проблема: кто может подтвердить подлинность сертификата центра верхнего уровня, у которого нет издателя? В этом исключительном случае сертификат является «самоподписанным»: его издатель совпадает с субъектом. Браузеры заранее настроены доверять известным удостоверяющим центрам, однако при доверии самоподписанному сертификату важно проявлять особую осторожность. Широкая публикация открытого ключа корневым центром снижает риск доверия к этому ключу: было бы очевидно, если бы кто-то другой опубликовал ключ, выдавая себя за этот центр.

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

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

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

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

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

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

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

Протокол SSL — это протокольный уровень, который можно разместить между надёжным протоколом сетевого уровня с установлением соединения (например, 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. Необязательная аутентификация клиента сервером

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

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

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

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

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

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

• Без дайджеста (вариант Null)
• MD5 — 128-битная хеш-функция
• Алгоритм безопасного хеширования (SHA-1) — 160-битная хеш-функция

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

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

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

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

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

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

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

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

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

Рисунок 3: Протокол записи SSL

Защита связи по 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. См. 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.