Спустя 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.2 процесс установления соединения проходит в несколько этапов:
TLS 1.3 в 2 раза ускоряет весь процесс за счет объединения нескольких шагов, сокращая время до начала обмена информацией. Последовательность получается следующая:
При этом сам механизм стал более безопасным, так как разработчики удалили все алгоритмы, которые не используют AEAD-режимы блочного шифрования. При этом в структуре типовых шифронаборов механизмы аутентификации и обмена ключами были «отделены» от алгоритма защиты записи и хеш-функции для HMAC.
Это нововведение не позволит злоумышленникам использовать скопированные ключи одной сессии для расшифровки других данных. Даже в случае компрометации мастер-ключа, сессионные ключи не будут взломаны.
Режим, в котором сервер и клиент могут установить соединение по старым ключам, если они уже обменивались пакетами. Такой подход сократит время до начала приема-передачи данных.
Однако в этом случае клиент (например, браузер) не устанавливает защищенный канал с сервером, а просто посылает запрос. При этом злоумышленники могут перехватить пакет и при желании подделать его. Поэтому в спецификации протокола отдельно рассмотрены атаки повторного воспроизведения (Replay Attacks), которые реализуются путём записи и последующей отправки ранее посланных корректных сообщений, и способы противодействия им.
Здесь важно помнить, что ответственность за реализацию защиты от подобных атак несет сервер, поэтому в документе IETF сделан особый упор на механизмы защиты, которые бы противодействовали деятельности злоумышленников. С предлагаемыми подходами можно ознакомиться по ссылке.
Описание других функций и особенностей стандарта можно найти здесь.
P.S. Несколько материалов из Первого блога о корпоративном IaaS:
P.P.S. Подборка статей из блога «ИТ-ГРАД» на Хабре:
/ фото 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. Подборка статей из блога «ИТ-ГРАД» на Хабре:
Комментарии (9)
gonchik
04.04.2018 08:16Спасибо большое за статью! Поясните пожалуйста, про нововведения 0-RT и forward secrecy. Один разрешает использовать старые ключи для продления сессии, другой даёт возможность защиты но в качестве рекомендации к инженерам серверной части от replay атак. Правильно ли я, понял?
KodyWiremane
И что банки?
mediaman
Вероятно, у банков нет выбора и им придется разрабатывать нужное решение для просмотра трафика самостоятельно.
А другие компании уже работают с TLS 1.3 – еще до утверждения можно было активировать в браузерах; в Cisco готовят решения для защиты трафика с учетом новых возможностей протокола.
9660
Так 1.3 якобы технически подобное не позволяет. Поэтому действительно интересно про банки.
Prototik
Дык никто не запрещает впарить свой сертификат CA и устроить проксю для TLS трафика. Просто им придётся разработать *другое* решение, а не использовать такое-же, как было до TLS 1.3.
Goodkat
А зачем банкам просматривать трафик?
tmvrus
В целях обеспечения корпоративной безопасности(следить за сотрудниками).
Goodkat
А, вы про внутренний трафик?!
Я уж подумал про трафик клиентов.
Sklott
Если я все правильно понял (глубоко не вникал), то раньше банки могли «отдать» статические ключи которыми шифровали трафик некоей «контролирующей организации» и она могла весь трафик к этим банкам расшифровать и смотреть.
Сейчас, т.к. нету статических ключей, нужно либо громоздить инфраструктуру по передаче эфемерных, либо ставить mitmproxy, либо еще что-то такое придумывать…