Спустя 4 года и 28 драфтов, Инженерный совет Интернета (IETF) одобрил обновленный протокол TLS 1.3. Далее расскажем, в чем причина длительного утверждения протокола, и поговорим о его особенностях.
/ фото Solo se puede CC
Почему так долго
Утверждение новой версии протокола заняло столько времени, так как обновление вызвало у некоторых компаний, в частности, банков, опасения. TLS 1.3 не позволяет расшифровывать проходящий трафик в сети, так как архитектура нового протокола использует эфемерные ключи вместо статических. Банкам необходимо анализировать трафик, чтобы обеспечить прозрачность подключений: ЦОД для финансовых организаций обычно подчиняется определенным требованиям (например, требованиям стандарта PCI DSS).
Для того чтобы получить возможность отслеживать трафик, некоторые операторы предложили встроить в протокол своеобразный «бэкдор»: внедрить статический протокол Диффи — Хеллмана. Обсуждение этого вопроса и задержало одобрение TLS. Отметим, что инициатива все же была отклонена.
Первая причина отказа заключается в том, что использование статического протокола Диффи — Хеллмана позволит прослушивать сеть, а это нарушение RFC 2804 IETF Policy on Wiretapping.
Вторая причина — неготовность рабочих групп IETF стандартизировать поддержку слабого шифрования в новом протоколе. Как показывает история, использование слабых алгоритмов шифрования, например, шифров RSA экспортного класса, может привести к таким атакам, как man-in-the-middle. Поэтому в IETF не согласились задействовать менее защищенные версии TLS, даже если это усложнит работу сетевых провайдеров.
На пути TLS 1.3 также встал случай с Хромбуками. В январе 2017 года Google представили релиз Chrome 56 с поддержкой TLS 1.3, доступный для устройств на Linux, macOS, Windows, Android и iOS. Но после обновления Chrome до новой версии, Хромбуки и Windows-ПК в школах округа Монтгомери, США, не смогли подключиться к сети.
Позже выяснилось, что причиной сбоя стал инструмент безопасности Blue Coat 6.5. Он «вешал» систему, если Chrome устанавливал соединение по TLS 1.3, так как разработчики не до конца следовали спецификациям Google. В итоге ИТ-гигант временно приостановил внедрение протокола.
/ фото Jack-Benny Persson CC
Главные особенности TLS 1.3
В TLS 1.3 разработчики сделали несколько существенных изменений, по сравнению с предыдущей версией протокола.
Изменили процедуру «рукопожатия»
При использовании TLS 1.2 процесс установления соединения проходит в несколько этапов:
- Сперва клиент обращается к серверу и предлагает ряд систем шифрования, с которыми он может работать.
- Сервер отвечает клиенту, сообщает, какую систему шифрования он будет использовать, и отправляет ключ шифрования.
- Клиент получает ключ и использует его для шифрования и отправки случайной последовательности символов.
- Далее создаются 2 новых ключа: мастер-ключ (сильнее) и сессионный ключ (слабее).
- Далее, клиент сообщает, какую систему шифрования он планирует использовать для сессионного ключа.
- Наконец, сервер одобряет систему шифрования и начинается обмен данными.
TLS 1.3 в 2 раза ускоряет весь процесс за счет объединения нескольких шагов, сокращая время до начала обмена информацией. Последовательность получается следующая:
- Клиент сообщает серверу о системах шифрования, с которыми он может работать.
- Сервер одобряет системы и передает свой ключ.
- Клиент предоставляет сессионные ключи.
При этом сам механизм стал более безопасным, так как разработчики удалили все алгоритмы, которые не используют AEAD-режимы блочного шифрования. При этом в структуре типовых шифронаборов механизмы аутентификации и обмена ключами были «отделены» от алгоритма защиты записи и хеш-функции для HMAC.
Внедрили forward secrecy
Это нововведение не позволит злоумышленникам использовать скопированные ключи одной сессии для расшифровки других данных. Даже в случае компрометации мастер-ключа, сессионные ключи не будут взломаны.
Добавили режим 0-RTT
Режим, в котором сервер и клиент могут установить соединение по старым ключам, если они уже обменивались пакетами. Такой подход сократит время до начала приема-передачи данных.
Однако в этом случае клиент (например, браузер) не устанавливает защищенный канал с сервером, а просто посылает запрос. При этом злоумышленники могут перехватить пакет и при желании подделать его. Поэтому в спецификации протокола отдельно рассмотрены атаки повторного воспроизведения (Replay Attacks), которые реализуются путём записи и последующей отправки ранее посланных корректных сообщений, и способы противодействия им.
Здесь важно помнить, что ответственность за реализацию защиты от подобных атак несет сервер, поэтому в документе IETF сделан особый упор на механизмы защиты, которые бы противодействовали деятельности злоумышленников. С предлагаемыми подходами можно ознакомиться по ссылке.
Описание других функций и особенностей стандарта можно найти здесь.
P.S. Несколько материалов из Первого блога о корпоративном IaaS:
- Особенности двухфакторной аутентификации: работает ли это в облаке IaaS
- Государственные системы в облаке: особенности размещения
- Защита персональных данных: европейский подход
P.P.S. Подборка статей из блога «ИТ-ГРАД» на Хабре:
- Slingshot APT: найден продвинутый вирус — он оставался незамеченным 6 лет
- Новый вирус Reaper заразил 2 миллиона IoT-устройств
- Последнее обновление для HPE ProLiant выводило из строя сетевые адаптеры
Автор: ИТ-ГРАДовец
