Протоколы Internet


Протокол TLS версия 0 - часть 46


/p>

Запросы возобновления 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, серверы, которые получают блоки, заполненные по такой схеме, продолжают свою работу обычным образом.

F. Анализбезопасности

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

F.1. Протокол диалога

Протокол диалога несет ответственность за выбор CipherSpec и генерацию мастерного секретного кода (Master Secret), которые вместе являются первичными криптографическими параметрами, сопряженными с безопасной сессией. Протокол диалога может также аутентифицировать партнеров, которые имеют сертификаты, подписанные пользующимся доверием провайдером сертификатов.

F.1.1. Аутентификация и обмен ключами

TLS поддерживает три режима аутентификации: аутентификация обоих партнеров, аутентификация сервера не аутентифицированным клиентом, и полностью анонимная. Всякий раз, когда сервер аутентифицирован, канал безопасен со стороны атак 'посредника' (man-in-the-middle), по анонимные сессии полностью беззащитны для такого рода атак. Анонимные серверы не могут аутентифицировать клиентов. Если сервер аутентифицирован, его сообщение сертификата должно предоставить корректную сертификационную цепочку, ведущую к приемлемому провайдеру сертификатов. Аналогично, аутентифицированные клиенты должны предоставить приемлемый сертификат серверу. Каждый партнер ответственен за верификацию сертификата противоположной стороны, за его пригодность.




Начало  Назад  Вперед