Приложения

Приложения

На главную страницу


Приложение A. ASN.1 синтаксис сертификатов

Сертификаты используются SSL для аутентификации серверов и клиентов. SSL Сертификаты базируются в основном на X.509. Сертификат X.509 содержит следующую информацию (в нотации ASN.1):

X.509-Certificate ::= SEQUENCE { certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier, signature BIT STRING }

CertificateInfo ::= SEQUENCE { version [0] Version DEFAULT v1988,

serialNumber CertificateSerialNumber, signature AlgorithmIdentifier,
issuer Name, validity Validity, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo }

Version ::= INTEGER { v1988(0) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime }

SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }

AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY ALGORITHM OPTIONAL }
Для целей SSL наложены ограничения на некоторые значения полей X.509:

Сертификаты верифицируются в несколько шагов. Во-первых, проверяется подпись сертификата и, если она некорректна, некорректен и сертификат (произошла транспортная ошибка или попытка модификации). Далее верифицируется поле CertificateInfo::issuer. Там должна быть ссылка на эмитента, которому приложение доверяет. Поле CertificateInfo::validity проверяется на текущую дату и верифицируется.

Наконец, проверяется поле CertificateInfo::subject. Эта проверка опционна и зависит от уровня доверия, необходимого приложению, которое использует SSL.

Приложение B. Идентификаторы объектов и типов атрибутов

SSL использует субнабор X.520 типов атрибутов, а также несколько специфических идентификаторов объектов. Будущие модификации протокола SSL смогут поддерживать больше типов атрибутов и больше идентификаторов объектов.

Таблица 5. B.1. Выбранные типы атрибутов

commonName { attributeType 3 }

Общее имя, содержащееся в поле эмитента сертификата или субъекта сертификата.

countryName { attributeType 6 }

Название страны.

localityName { attributeType 7 }

Название местоположения.

stateOrProvinceName { attributeType 8 }

Название штата или провинции.

organizationName { attributeType 10 }

Название организации.

organizationalUnitName { attributeType 11 }

Название подразделения.

B.2. Идентификаторы объекта

md2withRSAEncryption { ... pkcs(1) 1 2 }

Идентификатор объекта для цифровой подписи, которая используется при шифровании MD2 и RSA. Применяется при SSL-верификации подписи сертификата.

md5withRSAEncryption { ... pkcs(1) 1 4 }

Идентификатор объекта для цифровой подписи, которая используется при шифровании MD5 и RSA. Применяется при SSL-верификации подписи сертификата.

rc4 { ... rsadsi(113549) 3 4 }

Алгоритм симметричного поточного шифра RC4, используемый SSL для массового шифрования.

Приложение C. Значения протокольных констант

Ниже рассмотрены различные протокольные константы. Одна вещь требует особого упоминания - IANA зарезервировала номер порта для "https" (HTTP использующий SSL). Этот порт имеет номер 443.

C.1. Коды версии протокола

#define SSL_CLIENT_VERSION 0x0002
#define SSL_SERVER_VERSION 0x0002

C.2. Коды протокольных сообщений

Определены следующие значения для кодов сообщений, которые используются версией 2 протокола диалога SSL.

#define SSL_MT_ERROR 0
#define SSL_MT_CLIENT_HELLO 1
#define SSL_MT_CLIENT_MASTER_KEY 2
#define SSL_MT_CLIENT_FINISHED 3
#define SSL_MT_SERVER_HELLO 4
#define SSL_MT_SERVER_VERIFY 5
#define SSL_MT_SERVER_FINISHED 6
#define SSL_MT_REQUEST_CERTIFICATE 7
#define SSL_MT_CLIENT_CERTIFICATE 8

C.3. Коды сообщений об ошибках

Определены следующие значения для кодов ошибок, используемых в сообщениях ERROR.

#define SSL_PE_NO_CIPHER 0x0001
#define SSL_PE_NO_CERTIFICATE 0x0002
#define SSL_PE_BAD_CERTIFICATE 0x0004
#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006

C.4. Значения вида шифра

Определены следующие значения для кодов CIPHER-KIND, используемых в сообщениях CLIENT-HELLO и SERVER-HELLO.

#define SSL_CK_RC4_128_WITH_MD5 0x01,0x00,0x80
#define SSL_CK_RC4_128_EXPORT40_WITH_MD5 0x02,0x00,0x80
#define SSL_CK_RC2_128_CBC_WITH_MD5 0x03,0x00,0x80
#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 0x04,0x00,0x80
#define SSL_CK_IDEA_128_CBC_WITH_MD5 0x05,0x00,0x80
#define SSL_CK_DES_64_CBC_WITH_MD5 0x06,0x00,0x40
#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5 0x07,0x00,0xC0

C.5. Коды типа сертификата

Определено следующее значение для кода типа сертификации, используемое в сообщениях SERVER-HELLO и CLIENT-CERTIFICATE.

#define SSL_CT_X509_CERTIFICATE 0x01

C.6. Коды типов аутентификации

Определено следующее значение для кода типа аутентификации, используемое в сообщениях REQUEST-CERTIFICATE.

#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01

C.7. Верхние/нижние ограничения

Следующие величины определяют верхние/нижние ограничения для различных протокольных параметров.

#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256
#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16
#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64
#define SSL_MAX_RECORD_LENGTH_2_BYTE_headER 32767
#define SSL_MAX_RECORD_LENGTH_3_BYTE_headER 16383

Приложение D: Атаки

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

D.1. Раскрытие шифров

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

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

D.2. Атака открытого текста

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

Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4.

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

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

Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость его раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей "дикого хакера".

D.3. Атака отклика

Атака отклика достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента.

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

Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать "правильную" сессию, основываясь на коде nonce, посланном сервером посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 264 кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными.

D.4. Человек посередине

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

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

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

Патентное заявление

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

Массачусетский Технологический институт и Совет попечителей Стэнфордского университета (Leland) предоставили эксклюзивные права PKP (Public Key Partners) на следующие патенты США и все соответствующие зарубежные патенты:

Криптографическое устройство и метод (Diffie-Hellman) No. 4,200,770
Устройство и метод для криптографии с общедоступным ключом (Hellman-Merkle) No. 4,218,582
Криптографическая коммуникационная система и метод (RSA) No. 4,405,829
Устройство и метод экспоненциальной криптографии (Hellman-Pohlig) No. 4,424,414

Эти патенты объявлены PKP покрывающими все известные методы шифрования с общедоступным ключом, включая вариации, базирующиеся на алгоритме Эль Гамаля.

Группа PKP предоставила письменные гарантии Интернет сообществу, что участники могут получить на разумных не дискриминирующих условиях права на использование технологий, покрываемых этими патентами. Эта гарантия представлена в документе RFC 1170 "Public Key Standards и Licenses". Данный документ датирован 20 апреля 1990, и может быть получен в IANA (Internet Assigned Number Authority).

back contents next