Интегрированные сети ISDN
F Анализбезопасности
F. Анализбезопасности
Протокол TLS создан для того, чтобы установить безопасное соединение между клиентом и сервером через канал не гарантирующий безопасность. В данном документе делаются несколько традиционных предположений, включая то, что атакующие имеют достаточно большие вычислительные ресурсы и не могут получить секретную информацию из источников, помимо протокольных. Предполагается, что атакующий может перехватить, модифицировать, уничтожать и подменить сообщения, посланные по коммуникационному каналу.
F.1. Протокол диалога
Протокол диалога несет ответственность за выбор CipherSpec и генерацию мастерного секретного кода (Master Secret), которые вместе являются первичными криптографическими параметрами, сопряженными с безопасной сессией. Протокол диалога может также аутентифицировать партнеров, которые имеют сертификаты, подписанные пользующимся доверием провайдером сертификатов.
F.1.1. Аутентификация и обмен ключами
TLS поддерживает три режима аутентификации: аутентификация обоих партнеров, аутентификация сервера не аутентифицированным клиентом, и полностью анонимная. Всякий раз, когда сервер аутентифицирован, канал безопасен со стороны атак 'посредника' (man-in-the-middle), по анонимные сессии полностью беззащитны для такого рода атак. Анонимные серверы не могут аутентифицировать клиентов. Если сервер аутентифицирован, его сообщение сертификата должно предоставить корректную сертификационную цепочку, ведущую к приемлемому провайдеру сертификатов. Аналогично, аутентифицированные клиенты должны предоставить приемлемый сертификат серверу. Каждый партнер ответственен за верификацию сертификата противоположной стороны, за его пригодность.
Общей целью процесса ключевого обмена является формирование pre_master_secret, известного партнерами обмена, но неизвестного хакерам. Код pre_master_secret будет использован для генерации master_secret (смотри раздел 8.1). Код master_secret необходим, чтобы сформировать сообщения верификации сертификата, шифровальных ключей, секретных кодов MAC финального сообщения (смотри разделы 7.4.8, 7.4.9 и 6.3).
Путем посылки корректного финального сообщения (finished) партнеры подтверждают то, что они знают правильное значение pre_master_secret.
F.1.1.1. Анонимный обмен ключами
Полностью анонимные сессии могут быть реализованы с помощью ключевого обмена на основе алгоритмов RSA или Diffie-Hellman. При анонимном RSA, клиент шифрует pre_master_secret с помощью не сертифицированного общедоступного ключа сервера, полученного из его сообщения ключевого обмена. Результат посылается в сообщении ключевого обмена клиента. Так как злоумышленники не знают секретного ключа сервера, практически не реально для них дешифровать pre_master_secret. Заметим, что анонимные шифровые RSA-наборы в данном документе не определены.
В случае алгоритма Diffie-Hellman, общедоступные параметры сервера содержатся в его сообщении ключевого обмена, а параметры клиента посылаются в его сообщении ключевого обмена. Злоумышленники, которые не знают секретных ключей, не способны выполнить вычисления согласно алгоритму Diffie-Hellman и получить правильный результат (т.e. pre_master_secret).
Полностью анонимные соединения предоставляют защиту только против пассивных видов атак. Если только не используется надежно защищенный канал, позволяющий проверку того, что финальное сообщение не подменено злоумышленником, в ситуациях, где возможна активная атака 'посредника' (man-in-the-middle) необходима аутентификация сервера.
F.1.1.2. Обмен ключами по схеме RSA с аутентификацией
В случае RSA, ключевой обмен и аутентификация сервера совмещаются. Общедоступный ключ может содержаться в сертификате сервера или быть временным RSA-ключом, посланным в сообщении ключевого обмена сервера. Когда используются временные RSA-ключи, они подписываются сертификатом сервера RSA или DSS. Подпись включает текущее значение ClientHello.random, поэтому старые подписи и временные ключи не могут быть повторно использованы. Серверы могут использовать одиночный временный RSA-ключ для нескольких сессий.
Опция временного ключа RSA полезна, если серверы нуждаются в больших сертификатах, но вынуждены соглашаться с правительственными регламентациями для размеров ключей при ключевом обмене.
После проверки сертификата сервера, клиент шифрует pre_master_secret с помощью общедоступного ключа сервера. В случае успешной дешифровки pre_master_secret и выработки корректного финального сообщения, сервер демонстрирует, что он знает секретный ключ, соответствующий его сертификату.
Когда RSA используется для ключевого обмена, клиенты аутентифицируются, используя сообщение верификации сертификата (смотри раздел 7.4.8). Клиент подписывает значение, полученное из master_secret и все предыдущие сообщения диалога. Эти сообщения диалога включают сертификат сервера, который связывает подпись с сервером, и ServerHello.random, связывающий подпись с текущим процессом диалога.
F.1.1.3. Обмен ключами по схеме Diffie-Hellman с аутентификацией
Когда используется пересылка ключей по схеме Diffie-Hellman, сервер может либо предоставить сертификат, содержащий фиксированные параметры Diffie-Hellman, либо использовать сообщение ключевого обмена сервера, чтобы послать набор временных параметров, подписанных сертификатом DSS или RSA. Временные параметры хэшируются со значениями hello.random до формирования подписи, чтобы гарантировать, что злоумышленник не сможет воспользоваться старыми параметрами. В любом случае клиент может проверить сертификат или подпись, чтобы убедиться в том, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий фиксированные параметры Diffie-Hellman, его сертификат содержит информацию, необходимую для ключевого обмена. Заметим, что в этом случае клиент и сервер получат один и тот же результат (т.e., pre_master_secret) каждый раз, когда они обмениваются информацией. Чтобы предотвратить пребывание в памяти pre_master_secret дольше, чем это требуется, этот код должен быть, как можно быстрее преобразован в master_secret. Параметры клиента Diffie-Hellman должны быть совместимыми с теми, что поставляются сервером для ключевого обмена.
Если клиент имеет стандартный сертификат DSS или RSA или он не аутентифицирован, тогда клиент посылает набор временных параметров серверу в сообщении ключевого обмена клиента, затем опционно использует сообщение верификации сертификата, чтобы аутентифицировать себя.
F.1.2. Атаки понижения версии
Так как TLS содержит существенные улучшения по сравнению с SSL версии 2.0, атакующие могут попытаться создавать TLS-совместимых клиентов и серверов, чтобы вернуться к версии 2.0. Эта атака может произойти, если (и только если) два TLS-совместимых партнера используют диалог в SSL 2.0.
Хотя решение, использующее неслучайное заполнение сообщения блока PKCS #1 типа 2, не является красивым, оно предоставляет безопасный путь для серверов версии 3.0, чтобы заметить такую атаку. Это решение не безопасно по отношению злоумышленников, которые могут попытаться подсунуть ключ и осуществить подмену сообщения ENCRYPTED-KEY-DATA, содержащего тот же ключ (но с нормальным заполнителем) до момента истечения порога ожидания, заданного приложением. Партнеры, озабоченные атаками этого типа, никогда не должны использовать 40-битовые ключи шифрования. Вариация заполнителя младших 8 байт PKCS не увеличивает безопасности, так как это просто эквивалентно увеличению размера входного блока на 8 байт.
F.1.3. Регистрация атак против протокола диалога
Атакующий может попытаться повлиять на диалоговый обмен, чтобы заставить партнеров выбрать другой алгоритм шифрования, отличный от того, который бы они выбрали сами. Так как многие реализации будут поддерживать 40-битовое экспортное шифрование, а некоторые могут даже поддерживать отсутствие шифрования или алгоритмы MAC, возможность такой атаки должна всегда учитываться.
Для этой атаки злоумышленник должен активно изменить одно или более сообщений диалога. Если это произойдет, клиент и сервер вычислят разные значения для хэшей сообщения диалога. В результате, партнеры не воспримут друг от друга финальные сообщения. Без master_secret, злоумышленник не может восстановить финальные сообщения, таким образом, факт атаки будет раскрыт.
F.1.4. Возобновляемые сессии
Когда соединение установлено путем возобновления сессии, новые значения ClientHello.random и ServerHello.random хэшируются вместе с master_secret сессии.
Если установлено, что код master_secret не поврежден и что хэш-операции, использованные для получения ключей и секретных кодов MAC также безопасны, то соединение можно считать безопасным и независимым от предыдущих соединений. Атакующие не могут использовать известные ключи шифрования или секретные коды MAC, для того, чтобы скомпрометировать master_secret без нарушения исполнения операций хэширования.
Сессии не могут возобновляться, если только клиент и сервер не хотят этого. Если любой из партнеров подозревает, что сессия скомпрометирована, или что сертификаты не действительны, он должен потребовать полного диалога. Для верхнего предела времени жизни идентификатора сессии предлагается значение 24 часа, так как атакующий, получивший значение master_secret может подменить скомпрометированного партнера пока сохраняется старое значение ID-сессии. Приложения, которые могут работать в относительно небезопасной среде не должны записывать ID-сессии в постоянную память.
F.1.5. MD5 и SHA
TLS использует хэш-функции весьма консервативно. Где возможно, как MD5, так и SHA используются вместе для того, чтобы не катастрофические дефекты в одном алгоритме не приводили к разрушения всего протокола.
F.2. Защита прикладных данных
Код master_secret кэшируется с помощью ClientHello.random и ServerHello.random, чтобы получить уникальные ключи для шифрования данных и секретные коды MAC для каждого соединения. Исходящие данные перед посылкой защищаются с помощью MAC. Для того чтобы исключить атаки, связанные с модификаций или воспроизведения сообщений, из секретного кода MAC вычисляется MAC, номер по порядку, длина сообщения, содержимое сообщения и две фиксированные символьные строки. Поле типа сообщения необходимо, чтобы гарантировать то, что сообщения, предназначенные для одного клиента слоя записи TLS, не будут переадресованы другому. Номер по порядку гарантирует, что попытки уничтожить или поменять порядок сообщений будут детектированы. Так как номера по порядку имеют 64 бита, они не могут быть переполнены.Сообщения от одного партнера не могут быть вставлены в выходные сообщения другого, так как они используют независимые секретные коды MAC. Аналогично, ключи записи сервера и клиента независимы, так что ключи поточных шифров используются только раз.
Если атакующий расколол ключ шифрования, все сообщения, зашифрованные этим ключом, могут быть прочитаны. Аналогично, раскрытие ключа MAC может сделать возможной атаку, сопряженную с модификацией передаваемых сообщений. Так как MAC зашифрован, атаки модификации сообщений требуют также взлома и алгоритма шифрования.
Секретные коды MAC могут быть больше, чем ключи шифрования, поэтому сообщения могут оставаться устойчивы против повреждений, даже если взломаны ключи шифрования.
