Спустя 4 года и 28 драфтов, Инженерный совет Интернета (IETF) одобрил ^[1] обновленный протокол TLS 1.3. Далее расскажем, в чем причина длительного утверждения протокола, и поговорим о его особенностях.

^[2]
/ фото Solo se puede ^[3] CC ^[4]

Почему так долго

Утверждение новой версии протокола заняло столько времени, так как обновление вызвало у некоторых компаний, в частности, банков, опасения. TLS 1.3 не позволяет расшифровывать проходящий трафик в сети, так как архитектура нового протокола использует эфемерные ^[5] ключи вместо статических ^[6]. Банкам необходимо анализировать трафик, чтобы обеспечить прозрачность подключений: ЦОД для финансовых организаций обычно подчиняется определенным требованиям ^[7] (например, требованиям стандарта PCI DSS ^[8]).

Для того чтобы получить возможность отслеживать трафик, некоторые операторы предложили ^[9] встроить в протокол своеобразный «бэкдор»: внедрить статический протокол ^[10] Диффи — Хеллмана. Обсуждение этого вопроса и задержало одобрение TLS. Отметим, что инициатива все же была отклонена.

Первая причина отказа заключается в том, что использование статического протокола Диффи — Хеллмана позволит прослушивать сеть, а это нарушение RFC 2804 ^[11] IETF Policy on Wiretapping.

Вторая причина — неготовность ^[12] рабочих групп IETF стандартизировать поддержку слабого шифрования в новом протоколе. Как показывает история, использование слабых алгоритмов шифрования, например, шифров RSA экспортного класса, может привести к таким атакам, как man-in-the-middle. Поэтому в IETF не согласились задействовать менее защищенные версии TLS, даже если это усложнит работу сетевых провайдеров.

На пути TLS 1.3 также встал ^[13] случай с Хромбуками. В январе 2017 года Google представили релиз Chrome 56 с поддержкой TLS 1.3, доступный для устройств на Linux, macOS, Windows, Android и iOS. Но после обновления Chrome до новой версии, Хромбуки и Windows-ПК в школах округа Монтгомери, США, не смогли подключиться к сети.

Позже выяснилось, что причиной сбоя стал инструмент безопасности Blue Coat 6.5. Он «вешал» систему, если Chrome устанавливал соединение по TLS 1.3, так как разработчики не до конца следовали спецификациям Google. В итоге ИТ-гигант временно приостановил ^[1] внедрение протокола.

/ фото Jack-Benny Persson ^[14] CC ^[15]

Главные особенности TLS 1.3

В TLS 1.3 разработчики сделали несколько существенных изменений, по сравнению с предыдущей версией протокола.

Изменили процедуру «рукопожатия»

При использовании TLS 1.2 процесс установления соединения проходит ^[1] в несколько этапов:

• Сперва клиент обращается к серверу и предлагает ряд систем шифрования, с которыми он может работать.
• Сервер отвечает клиенту, сообщает, какую систему шифрования он будет использовать, и отправляет ключ шифрования.
• Клиент получает ключ и использует его для шифрования и отправки случайной последовательности символов.
• Далее создаются 2 новых ключа: мастер-ключ (сильнее) и сессионный ключ (слабее).
• Далее, клиент сообщает, какую систему шифрования он планирует использовать для сессионного ключа.
• Наконец, сервер одобряет систему шифрования и начинается обмен данными.

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

• Клиент сообщает серверу о системах шифрования, с которыми он может работать.
• Сервер одобряет системы и передает свой ключ.
• Клиент предоставляет сессионные ключи.

При этом сам механизм стал более безопасным, так как разработчики удалили все алгоритмы, которые не используют AEAD-режимы блочного шифрования ^[16]. При этом в структуре типовых шифронаборов механизмы аутентификации и обмена ключами были «отделены» от алгоритма защиты записи и хеш-функции для HMAC ^[17].

Внедрили forward secrecy

Это нововведение не позволит ^[18] злоумышленникам использовать скопированные ключи одной сессии для расшифровки других данных. Даже в случае компрометации мастер-ключа, сессионные ключи не будут взломаны.

Добавили режим 0-RTT

Режим, в котором сервер и клиент могут установить соединение по старым ключам, если они уже обменивались пакетами. Такой подход сократит время до начала приема-передачи данных.

Однако в этом случае клиент (например, браузер) не устанавливает защищенный канал с сервером, а просто посылает запрос. При этом злоумышленники могут перехватить пакет и при желании подделать его. Поэтому в спецификации протокола отдельно рассмотрены ^[19] атаки повторного воспроизведения (Replay Attacks ^[20]), которые реализуются путём записи и последующей отправки ранее посланных корректных сообщений, и способы противодействия им.

Здесь важно помнить, что ответственность за реализацию защиты от подобных атак несет сервер, поэтому в документе IETF сделан особый упор на механизмы защиты, которые бы противодействовали деятельности злоумышленников. С предлагаемыми подходами можно ознакомиться по ссылке ^[21].

Описание других функций и особенностей стандарта можно найти здесь ^[22].

---

P.S. Несколько материалов из Первого блога о корпоративном IaaS:

• Особенности двухфакторной аутентификации: работает ли это в облаке IaaS ^[23]
• Государственные системы в облаке: особенности размещения ^[24]
• Защита персональных данных: европейский подход ^[25]

P.P.S. Подборка статей из блога «ИТ-ГРАД» на Хабре:

• Slingshot APT: найден продвинутый вирус — он оставался незамеченным 6 лет ^[26]
• Новый вирус Reaper заразил 2 миллиона IoT-устройств ^[27]
• Последнее обновление для HPE ProLiant выводило из строя сетевые адаптеры ^[28]

Автор: ИТ-ГРАДовец

Источник ^[29]