«Интернет стал чуть безопаснее»: комитет IETF утвердил TLS 1.3

в 13:27, , рубрики: ietf, TLS, tls 1.3, Блог компании ИТ-ГРАД, информационная безопасность, ИТ-ГРАД

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

«Интернет стал чуть безопаснее»: комитет IETF утвердил TLS 1.3 - 1
/ фото 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. В итоге ИТ-гигант временно приостановил внедрение протокола.

«Интернет стал чуть безопаснее»: комитет IETF утвердил TLS 1.3 - 2
/ фото 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:

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

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

Источник

Поделиться

* - обязательные к заполнению поля