Протоколы Internet

         

сессии должны использовать сообщение TLS


/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), по анонимные сессии полностью беззащитны для такого рода атак. Анонимные серверы не могут аутентифицировать клиентов. Если сервер аутентифицирован, его сообщение сертификата должно предоставить корректную сертификационную цепочку, ведущую к приемлемому провайдеру сертификатов. Аналогично, аутентифицированные клиенты должны предоставить приемлемый сертификат серверу. Каждый партнер ответственен за верификацию сертификата противоположной стороны, за его пригодность.


Содержание  Назад  Вперед







Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий