Раздел 5. Шифрование Apache SSL/TLS RU EN Пункт 45. SSL/TLS: введение В качестве введения эта глава предназначена для читателей, знакомых с Web, HTTP и Apache, но не являющихся экспертами по безопасности. Он не претендует на то, чтобы быть окончательным руководством по протоколу SSL, и не обсуждает конкретные методы управления сертификатами в организации или важные юридические вопросы, связанные с патентами и ограничениями на импорт и экспорт. Скорее, он предназначен для предоставления общего фона Криптографические методыПонимание SSL требует понимания криптографических алгоритмов, функций дайджеста сообщений (они же односторонние или хеш-функции) и цифровых подписей. Этим методам посвящены целые книги (см., например, [AC96]), и они обеспечивают основу для конфиденциальности, целостности и аутентификации. Криптографические алгоритмыПредположим, Алиса хочет послать в свой банк сообщение о переводе денег. Алиса хотела бы, чтобы сообщение было частным, поскольку оно будет содержать такую информацию, как номер ее счета и сумма перевода. Одним из решений является использование криптографического алгоритма, метода, который преобразует ее сообщение в зашифрованную форму, нечитаемую до тех пор, пока оно не будет расшифровано. Находясь в этой форме, сообщение может быть расшифровано только с использованием секретного ключа. Без ключа сообщение бесполезно: хорошие криптографические алгоритмы настолько усложняют злоумышленникам декодирование исходного текста, что это не стоит их усилий. Существует две категории криптографических алгоритмов: обычные и с открытым ключом.
Любой может зашифровать сообщение с помощью открытого ключа, но прочитать его сможет только владелец закрытого ключа. Таким образом, Алиса может отправлять личные сообщения владельцу пары ключей (банку), шифруя их с помощью своего открытого ключа. Только банк сможет их расшифровать. Дайджесты сообщенийХотя Алиса может зашифровать свое сообщение, чтобы сделать его конфиденциальным, все еще существует опасение, что кто-то может изменить ее исходное сообщение или заменить его другим, например, для перевода денег себе. Один из способов гарантировать целостность сообщения Алисы состоит в том, чтобы она создала краткое изложение своего сообщения и также отправила его в банк. При получении сообщения банк создает собственную сводку и сравнивает ее с отправленной Алисой. Если сводки совпадают, то сообщение получено без изменений. Такая сводка называется дайджестом сообщения , односторонней функцией или хеш-функцией . Дайджесты сообщений используются для создания короткого представления фиксированной длины более длинного сообщения переменной длины. Алгоритмы дайджеста предназначены для создания уникального дайджеста для каждого сообщения. Дайджесты сообщений предназначены для того, чтобы сделать определение сообщения из дайджеста непрактичным и (теоретически) невозможным найти два разных сообщения, создающих один и тот же дайджест, что исключает возможность замены одного сообщения другим при сохранении одного и того же дайджеста. Еще одна проблема, с которой сталкивается Алиса, — найти способ надежно отправить дайджест в банк; если дайджест отправляется небезопасно, его целостность может быть нарушена, а вместе с этим и возможность для банка определить целостность исходного сообщения. Только в случае безопасной отправки дайджеста можно определить целостность связанного сообщения. Один из способов безопасно отправить дайджест — включить его в цифровую подпись. Цифровые подписиКогда Алиса отправляет сообщение в банк, банк должен убедиться, что сообщение действительно от нее, чтобы злоумышленник не смог запросить транзакцию с ее счетом. Этой цели служит цифровая подпись , созданная Алисой и включенная в сообщение. Цифровые подписи создаются путем шифрования дайджеста сообщения и другой информации (например, порядкового номера) с помощью закрытого ключа отправителя. Хотя любой может расшифровать подпись с помощью открытого ключа, только отправитель знает закрытый ключ. Это означает, что только отправитель может подписать сообщение. Включение дайджеста в подпись означает, что подпись подходит только для этого сообщения; это также гарантирует целостность сообщения, поскольку никто не может изменить дайджест и по-прежнему подписывать его. Для защиты от перехвата и повторного использования подписи злоумышленником позднее подпись содержит уникальный порядковый номер. Это защищает банк от мошеннических заявлений Алисы о том, что она не отправляла сообщение — только она могла его подписать (неотказуемость). СертификатыХотя Алиса могла бы отправить личное сообщение в банк, подписать его и обеспечить целостность сообщения, ей все равно нужно быть уверенным, что она действительно общается с банком. Это означает, что она должна быть уверена, что открытый ключ, который она использует, является частью пары ключей банка, а не злоумышленника. Точно так же банку необходимо убедиться, что подпись сообщения действительно была подписана закрытым ключом, принадлежащим Алисе. Если у каждой стороны есть сертификат, подтверждающий личность другой стороны, подтверждающий открытый ключ и подписанный доверенным агентством, то обе стороны могут быть уверены, что общаются с теми, с кем себя считают. Такое доверенное агентство называется Центром сертификации , и для аутентификации используются сертификаты. Содержание сертификатаСертификат связывает открытый ключ с реальной личностью человека, сервера или другого объекта, известного как субъект. Как показано в таблице 1, информация о субъекте включает в себя идентифицирующую информацию (отличительное имя) и открытый ключ. Он также включает идентификацию и подпись центра сертификации, выдавшего сертификат, и период времени, в течение которого сертификат действителен. Он может содержать дополнительную информацию (или расширения), а также административную информацию для использования Центром сертификации, например, серийный номер. Таблица 1: Информация о сертификате
Отличительное имя используется для предоставления удостоверения в определенном контексте — например, у человека может быть личный сертификат, а также один для его удостоверения в качестве сотрудника. Отличительные имена определяются стандартом X.509 [X509], который определяет поля, имена полей и сокращения, используемые для обозначения полей (см. Таблицу 2). Таблица 2: Информация об отличительном имени
Центр сертификации может определить политику, определяющую, какие отличительные имена полей являются необязательными, а какие обязательными. Он также может предъявлять требования к содержимому поля, как и пользователи сертификатов. Например, браузер Netscape требует, чтобы общее имя сертификата, представляющего сервер, совпадало с подстановочным знаком для доменного имени этого сервера, например Двоичный формат сертификата определяется с использованием нотации ASN.1 [ASN1] [PKCS]. Эта нотация определяет, как указывать содержимое, а правила кодирования определяют, как эта информация преобразуется в двоичную форму. Двоичное кодирование сертификата определяется с помощью специальных правил кодирования (DER), которые основаны на более общих базовых правилах кодирования (BER). Для тех передач, которые не могут обрабатывать двоичные данные, двоичная форма может быть преобразована в форму ASCII с использованием кодировки Base64 [MIME]. При размещении между начальной и конечной строками-разделителями (как показано ниже) эта закодированная версия называется закодированным сертификатом PEM («Privacy Enhanced Mail»). Пример сертификата в кодировке PEM (snakeoil.crt)-----НАЧАТЬ СЕРТИФИКАТ----- MIIC7jCCAlegAwIBAGIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa лWOANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV HRMECDAGAQH/AgeEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== -----КОНЕЦ СЕРТИФИКАТА----- Центры сертификацииПроверяя информацию в запросе сертификата перед выдачей сертификата, центр сертификации убеждается в подлинности владельца закрытого ключа пары ключей. Например, если Алиса запрашивает персональный сертификат, центр сертификации должен сначала убедиться, что Алиса действительно является тем человеком, которым она заявлена в запросе сертификата. Цепочки сертификатовЦентр сертификации может также выдать сертификат для другого центра сертификации. При проверке сертификата Алисе может потребоваться проверить сертификат эмитента для каждого родительского центра сертификации, пока не будет найден тот, которому она доверяет. Она может принять решение доверять только сертификатам с ограниченной цепочкой эмитентов, чтобы снизить риск "плохой" сертификат в цепочке. Создание ЦС корневого уровняКак отмечалось ранее, для каждого сертификата требуется, чтобы эмитент подтверждал действительность удостоверения субъекта сертификата вплоть до центра сертификации (ЦС) верхнего уровня. Возникает проблема: кто может поручиться за сертификат органа высшего уровня, у которого нет эмитента? В этом уникальном случае сертификат является «самоподписанным», поэтому издатель сертификата совпадает с субъектом. Браузеры предварительно настроены на доверие к известным центрам сертификации, но важно проявлять особую осторожность при доверии самозаверяющему сертификату. Широкая публикация открытого ключа корневым центром снижает риск доверия к этому ключу — было бы очевидно, если бы кто-то другой опубликовал ключ, претендующий на роль авторитета. Ряд компаний, таких как Thawte и VeriSign, зарекомендовали себя как центры сертификации. Эти компании предоставляют следующие услуги:
Также возможно создать свой собственный центр сертификации. Хотя это рискованно в среде Интернета, это может быть полезно во внутренней сети, где организация может легко проверить личность отдельных лиц и серверов. Управление сертификатамиСоздание центра сертификации — это ответственность, требующая надежной административной, технической и управленческой структуры. Центры сертификации не только выдают сертификаты, но и управляют ими, т. е. определяют, как долго сертификаты остаются в силе, обновляют их и ведут списки сертификатов, которые были выпущены в прошлом, но больше не действительны (списки отозванных сертификатов или CRL). Например, если Алиса имеет право на получение сертификата сотрудника компании, но теперь покинула эту компанию, ее сертификат может потребоваться отозвать. Поскольку сертификаты выдаются только после проверки личности субъекта и затем могут быть переданы всем тем, с кем субъект может общаться, по одному сертификату невозможно сказать, что он был отозван. Поэтому при проверке сертификатов на действительность необходимо связаться с выдавшим их центром сертификации для проверки CRL — обычно это не автоматизированная часть процесса. ПримечаниеЕсли вы используете центр сертификации, которому браузеры не настроены доверять по умолчанию, необходимо загрузить сертификат центра сертификации в браузер, чтобы браузер мог проверять сертификаты сервера, подписанные этим центром сертификации. Это может быть опасно, так как после загрузки браузер примет все сертификаты, подписанные этим центром сертификации. Уровень защищенных сокетов (SSL)Протокол уровня защищенных сокетов представляет собой уровень протокола, который может быть размещен между протоколом сетевого уровня, ориентированным на надежное соединение (например, TCP/IP), и уровнем протокола приложения (например, HTTP). SSL обеспечивает безопасную связь между клиентом и сервером, обеспечивая взаимную аутентификацию, использование цифровых подписей для обеспечения целостности и шифрование для обеспечения конфиденциальности. Протокол предназначен для поддержки ряда вариантов конкретных алгоритмов, используемых для криптографии, дайджестов и подписей. Это позволяет выбирать алгоритмы для конкретных серверов на основе юридических, экспортных или других соображений, а также позволяет протоколу использовать преимущества новых алгоритмов. Выбор согласовывается между клиентом и сервером при установлении сеанса протокола. Таблица 4: Версии протокола SSL
Существует несколько версий протокола SSL, как показано в Таблице 4. Как отмечено там, одним из преимуществ SSL 3.0 является добавленная поддержка загрузки цепочки сертификатов. Эта функция позволяет серверу передавать сертификат сервера вместе с сертификатами издателя в браузер. Загрузка цепочки также позволяет браузеру проверять сертификат сервера, даже если сертификаты центра сертификации не установлены для промежуточных эмитентов, поскольку они включены в цепочку сертификатов. SSL 3.0 является основой для стандарта протокола безопасности транспортного уровня [TLS], который в настоящее время разрабатывается Инженерной группой Интернета (IETF). Установление сеансаСеанс SSL устанавливается путем выполнения последовательности рукопожатий между клиентом и сервером, как показано на рис. 1. Эта последовательность может различаться в зависимости от того, настроен ли сервер для предоставления сертификата сервера или запроса сертификата клиента. Хотя существуют случаи, когда для управления информацией о шифровании требуются дополнительные шаги квитирования, в этой статье описан один распространенный сценарий. Полный спектр возможностей см. в спецификации SSL. ПримечаниеПосле того, как сеанс SSL установлен, его можно использовать повторно. Это позволяет избежать потери производительности из-за повторения многих шагов, необходимых для запуска сеанса. Для этого сервер присваивает каждому сеансу SSL уникальный идентификатор сеанса, который кэшируется на сервере и который клиент может использовать в будущих подключениях для сокращения времени рукопожатия (до истечения срока действия идентификатора сеанса из кэша сервера).
Элементы последовательности рукопожатия, используемые клиентом и сервером, перечислены ниже:
Первый шаг, согласование набора шифров, позволяет клиенту и серверу выбрать набор шифров, поддерживаемый ими обоими. Спецификация протокола SSL3.0 определяет 31 набор шифров. Набор шифров определяется следующими компонентами:
Эти три элемента описаны в следующих разделах. Метод обмена ключамиМетод обмена ключами определяет, как общий секретный симметричный криптографический ключ, используемый для передачи данных приложения, будет согласовываться между клиентом и сервером. SSL 2.0 использует только обмен ключами RSA, в то время как SSL 3.0 поддерживает выбор алгоритмов обмена ключами, включая обмен ключами RSA (при использовании сертификатов) и обмен ключами Диффи-Хеллмана (для обмена ключами без сертификатов или без предварительной связи между клиентом и сервером). ). Одной из переменных при выборе методов обмена ключами являются цифровые подписи — следует ли их использовать, и если да, то какие подписи использовать. Подписание закрытым ключом обеспечивает защиту от атаки «злоумышленник посередине» во время обмена информацией, используемого для создания общего ключа [AC96, p516]. Шифр для передачи данныхSSL использует обычную симметричную криптографию, как описано ранее, для шифрования сообщений в сеансе. Существует девять вариантов шифрования, включая вариант не шифровать:
«CBC» относится к цепочке шифровальных блоков, что означает, что часть ранее зашифрованного зашифрованного текста используется при шифровании текущего блока. «DES» относится к стандарту шифрования данных [AC96, ch12], который имеет несколько вариантов (включая DES40 и 3DES_EDE). «Идея» в настоящее время является одним из лучших и криптографически сильных доступных алгоритмов, а «RC2» — это проприетарный алгоритм RSA DSI [AC96, ch13]. Функция дайджестаВыбор функции дайджеста определяет, как дайджест создается из единицы записи. SSL поддерживает следующее:
Дайджест сообщения используется для создания кода аутентификации сообщения (MAC), который шифруется вместе с сообщением для проверки целостности и защиты от повторных атак. Протокол последовательности рукопожатияПоследовательность рукопожатия использует три протокола:
Эти протоколы, а также данные протоколов приложений инкапсулируются в протокол записи SSL , как показано на рис. 2. Инкапсулированный протокол передается как данные протоколом нижнего уровня, который не проверяет данные. Инкапсулированный протокол ничего не знает о базовом протоколе.
Инкапсуляция протоколов управления SSL протоколом записи означает, что при повторном согласовании активного сеанса протоколы управления будут передаваться безопасно. Если предыдущего сеанса не было, используется набор шифров Null, что означает, что шифрование не будет выполняться, и сообщения не будут иметь дайджестов целостности до тех пор, пока сеанс не будет установлен. Обмен даннымиПротокол записи SSL, показанный на рисунке 3, используется для передачи приложений и данных управления SSL между клиентом и сервером, при необходимости фрагментируя эти данные на более мелкие блоки или объединяя несколько сообщений данных протокола более высокого уровня в отдельные блоки. Он может сжимать, присоединять дайджест-подписи и шифровать эти блоки перед их передачей с использованием базового надежного транспортного протокола (Примечание: в настоящее время ни одна из основных реализаций SSL не поддерживает сжатие).
Защита HTTP-коммуникацийОдним из распространенных способов использования SSL является защита HTTP-соединения между браузером и веб-сервером. Это не исключает использования незащищенного HTTP — безопасная версия (называемая HTTPS) аналогична обычному HTTP через SSL, но использует схему URL, а не , и Рекомендации
|
 |
