Интегрированные сети ISDN

         

E Совместимость с SSL


E. Совместимость с SSL



По историческим причинам и для того чтобы избежать использования резервных номеров портов, прикладные протоколы, безопасность которых обеспечивается с помощью TLS 1.0, SSL 3.0, и SSL 2.0 часто используют один и тот же порт. Например: протокол HTTPS (HTTP с обеспечением безопасности за счет SSL или TLS) использует порт 443 вне зависимости от того, какой протокол безопасности применен. Таким образом, должен быть определен некоторый механизм согласования применения тех или иных протоколов.

TLS версии 1.0 и SSL 3.0 очень схожи. Клиенты TLS, которые желают согласовать применение SSL 3.0, должны посылать серверу сообщения client hello, используя формат записей SSL 3.0 и посылая {3, 1} в поле версии (TLS 1.0). Если сервер поддерживает только SSL 3.0, он откликнется server hello SSL 3.0. Если же он поддерживает TLS, то пришлет отклик TLS server hello. Дальнейшее согласование будет продолжено согласно с выбранным протоколом.

Аналогично, TLS-сервер, который хочет работать с клиентами SSL 3.0, должен воспринимать сообщения SSL 3.0 client hello и реагировать на server hello, если получено SSL 3.0 client hello с полем версии равным {3, 0}, означающим, что клиент не поддерживает TLS.

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

Клиенты TLS 1.0, которые поддерживают работу с серверами SSL версии 2.0, должны посылать сообщения client hello SSL версии 2.0 [SSL2]. Серверы TLS должны воспринимать любой формат client hello, если они хотят поддерживать работу с клиентами SSL 2.0, на том же порту соединения. Единственное отклонение спецификации от версии 2.0 является возможность специфицировать версию со значением три и поддерживать больше шифровых типов в CipherSpec.

Возможность посылать сообщения client hello версии 2.0 следует исключить из употребления так быстро, как это возможно. Разработчики должны предпринять все меры, чтобы ускорить эти работы.
Версия 3. 0 предоставляет лучшие механизмы для введения новых версий.

Следующие шифровые спецификации являются переходными от SSL версии 2.0. Они предполагают использования RSA для ключевого обмена и аутентификации.



V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 = { 0x04,0x00,0x80 };
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
Шифровые спецификации совместимые с TLS могут быть включены в сообщения client hello версии 2.0, используя описанный ниже синтаксис. Любой элемент V2CipherSpec с первым байтом равным нулю будет игнорироваться серверами версии 2.0. Клиенты, посылающие любую из перечисленных выше спецификаций V2CipherSpecs должны также включать и TLS-эквивалент (смотри приложение A.5):

V2CipherSpec (see TLS name) = { 0x00, CipherSuite };



E.1. Hello клиента версия 2



Сообщение client hello версии 2.0 представлены ниже. Истинные определения предполагаются совпадающими со спецификацией SSL версии 2.0.

uint8 V2CipherSpec[3];

struct { uint8 msg_type;

Version version;

uint16 cipher_spec_length;

uint16 session_id_length;

uint16 challenge_length;

V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];

opaque session_id[V2ClientHello.session_id_length];

Random challenge;

} V2ClientHello;

msg_type Это поле, в сочетании с полем версии, идентифицирует сообщение client hello версии 2. Значение поля должно быть равно единице (1).
Version Высшее значение версии протокола, поддерживаемое клиентом (равно ProtocolVersion.version, смотри приложение A.1).
cipher_spec_length Это поле равно полной длине поля cipher_specs. Оно не может быть равно нулю и должно быть кратным длине V2CipherSpec (3).
session_id_length Это поле должно иметь значение нуль или 16. Если равно нулю, клиент формирует новую сессию. Если равно 16, поле session_id будет содержать 16 байт идентификации сессии.
challenge_length Длина в байтах обращения клиента к серверу, чтобы аутентифицировать себя. Это значение должно равняться 32.
cipher_specs Это список всех CipherSpecs, которые клиент хочет и может использовать. Здесь должна быть по крайней мере одна спецификация CipherSpec, приемлемая для сервера.
session_id Если длина этого поля не равна нулю, оно будет содержать идентификатор сессии, которую клиент хочет возобновить.
Challenge Обращение клиента к серверу с целью идентификации самого себя. Его значение представляет собой псевдослучайное число произвольной длины. Сервер TLS проверяет обращение клиента, чтобы получить данные ClientHello.random (дополненные лидирующими нулями, если это нужно), как это специфицировано в данном протоколе. Если длина обращения больше чем 32 байта, то используются только последние 32 байта. Допускается (но не обязательно) для сервера V3 отклонять V2 ClientHello, которые имеют меньше 16 байтов обращения клиента.
Запросы возобновления TLS-сессии должны использовать сообщение TLS client hello.



E.2. Избежание атак понижения версии посредником (man-in-the-middle)



Когда клиенты TLS возвращаются к режиму совместимости с версией 2.0, они должны использовать специальное форматирование блоков PKCS #1. Это сделано так, что TLS-серверы будут отклонять сессии версии 2.0 с совместимыми TLS-клиентами.

Когда клиенты TLS работают в режиме совместимости с версией 2.0, они устанавливают правые случайные 8 байт (менее значимые) заполнителя PKCS (исключая завершающий нулевой заполнитель) для RSA-шифрования поля ENCRYPTED-KEY-DATA CLIENT-MASTER-KEY, равными 0x03 (остальные байты заполнителя содержат произвольные случайные значения). После дешифрования поля ENCRYPTED-KEY-DATA, серверы, которые получают блоки, заполненные по такой схеме, продолжают свою работу обычным образом.




Содержание раздела