TLS 1.3¶

TLS 1.3 (Transport Layer Security 1.3) — это версия криптографического протокола, обеспечивающего защищённую передачу данных между узлами в сети Интернет. Он является преемником TLS 1.2, разработанным рабочей группой IETF (Internet Engineering Task Force) и стандартизированным в августе 2018 года в документе RFC 8446. Основные цели создания TLS 1.3 — повышение безопасности за счёт устранения устаревших криптографических алгоритмов и снижение задержек при установлении соединения.

¶История разработки

Разработка TLS 1.3 началась в 2013 году на фоне накопления проблем в предыдущих версиях протокола. TLS 1.2 (стандартизирован в 2008 году) поддерживал множество криптографических опций, часть из которых со временем оказалась уязвимой. К 2014 году были выявлены атаки на TLS 1.2, такие как POODLE, BEAST, CRIME и другие, эксплуатирующие недостатки устаревших алгоритмов (например, RC4, CBC-mode cipher suites, сжатие на уровне протокола). Рабочая группа IETF решила не модифицировать TLS 1.2, а разработать новую версию с фундаментально упрощённой архитектурой.

Процесс стандартизации занял около пяти лет. Первые черновики (drafts) появились в 2014 году. В ходе обсуждений были отклонены предложения по включению некоторых экспериментальных механизмов (например, 0-RTT с дополнительными ограничениями). Финальная версия RFC 8446 была опубликована в августе 2018 года. После стандартизации началось внедрение протокола в веб-серверах, браузерах, операционных системах и библиотеках. К 2020 году поддержка TLS 1.3 стала стандартной для большинства современных веб-серверов и клиентов.

¶Архитектура и ключевые отличия от TLS 1.2

¶Упрощение набора шифров

В TLS 1.3 из обязательной поддержки исключены все симметричные шифры, использующие режимы CBC (Cipher Block Chaining), а также шифры RC4, 3DES и алгоритмы сжатия. Оставлены только шифры на основе AEAD (Authenticated Encryption with Associated Data): AES-GCM (Galois/Counter Mode) и ChaCha20-Poly1305. Для обмена ключами используются только алгоритмы на основе эллиптических кривых (ECDHE) и Диффи-Хеллмана на простых полях (DHE). RSA для обмена ключами исключён — теперь он применяется только для аутентификации (подписи сертификатов). Это устранило целый класс атак, связанных с уязвимостями в старых режимах шифрования.

¶Сокращение числа раундов рукопожатия

Рукопожатие (handshake) в TLS 1.3 выполняется за один круговой обход (1-RTT) вместо двух (2-RTT) в TLS 1.2. Это достигается за счёт того, что клиент в первом же сообщении отправляет не только список поддерживаемых алгоритмов, но и свой вклад в протокол Диффи-Хеллмана (ключ). Сервер, получив это сообщение, может сразу вычислить общий секрет и отправить свой вклад, сертификат и готовый ключ шифрования. Таким образом, установка защищённого соединения занимает одно сетевое путешествие (round trip), а не два.

¶Режим 0-RTT (early data)

TLS 1.3 поддерживает режим 0-RTT, при котором клиент, ранее уже установивший соединение с сервером, может отправить данные (например, HTTP-запрос) вместе с первым сообщением рукопожатия. Для этого используется «билет сессии» (session ticket), выданный сервером при предыдущем соединении. 0-RTT существенно снижает задержки для повторных подключений, однако имеет ограничения по безопасности: данные, отправленные в режиме 0-RTT, не защищены от повторной отправки (replay attack). Поэтому протокол рекомендует использовать 0-RTT только для идемпотентных запросов (например, GET-запросы, не изменяющие состояние сервера).

¶Удаление устаревших механизмов

Из TLS 1.3 полностью удалены:

• Сжатие на уровне протокола (было уязвимо к атакам CRIME/BREACH).
• Режим CBC для симметричного шифрования.
• Алгоритмы RSA и DH для обмена ключами (оставлены только ECDHE и DHE).
• Поддержка статических ключей RSA (сертификаты используются только для подписи).
• Механизм пересмотра версии (renegotiation), который был источником многих уязвимостей.
• Поддержка протокола SSL (все версии).

¶Процесс рукопожатия в TLS 1.3

¶Полное рукопожатие (1-RTT)

1. ClientHello: клиент отправляет серверу список поддерживаемых версий протокола, набор шифров (cipher suites), а также свой публичный ключ для ECDHE (или DHE).
2. ServerHello: сервер выбирает версию протокола и шифр, отправляет свой публичный ключ, сертификат (подписанный удостоверяющим центром) и подтверждение завершения рукопожатия (Finished), зашифрованное на общем ключе.
3. Клиент: проверяет сертификат сервера, вычисляет общий секрет, отправляет своё подтверждение (Finished). После этого обе стороны могут обмениваться зашифрованными данными.

¶Сокращённое рукопожатие (0-RTT)

Если клиент ранее подключался к серверу и получил «билет сессии» (session ticket), он может отправить в сообщении ClientHello не только ключ, но и зашифрованные данные (early data). Сервер, проверив билет, может сразу ответить данными. Однако, как упоминалось, данные 0-RTT уязвимы к повторной отправке, поэтому протокол предусматривает механизмы для ограничения риска (например, сервер может запросить подтверждение после получения данных).

¶Безопасность

TLS 1.3 считается значительно более безопасным, чем TLS 1.2, благодаря следующим особенностям:

• Полное исключение устаревших алгоритмов, которые были источниками атак (например, атака POODLE на CBC, атака Logjam на DH с малыми группами, атака Sweet32 на 3DES).
• Обязательное использование Perfect Forward Secrecy (PFS) — даже если долговременный ключ сервера (закрытый ключ сертификата) будет скомпрометирован, прошлые сеансы связи останутся защищёнными, так как сеансовые ключи вырабатываются на основе эфемерных ключей Диффи-Хеллмана.
• Упрощение структуры протокола снижает вероятность ошибок реализации.
• Поддержка только AEAD-шифров, которые обеспечивают одновременно конфиденциальность и целостность данных.

Однако TLS 1.3 не лишён ограничений. Режим 0-RTT создаёт риск повторной отправки данных, что требует осторожного применения. Кроме того, некоторые корпоративные сети, использующие прокси-серверы с инспекцией трафика (например, для фильтрации вредоносного контента), сталкиваются с трудностями при работе с TLS 1.3, так как протокол не поддерживает расширение для явного согласования прокси (хотя существуют отдельные расширения, например, TLS Proxy).

¶Применение

TLS 1.3 широко используется в современных веб-браузерах (Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge), веб-серверах (Apache, Nginx, IIS), почтовых клиентах, мессенджерах (например, Signal использует TLS 1.3 для защиты соединений) и других приложениях, работающих по протоколам HTTPS, SMTPS, IMAPS. Согласно отчётам организаций, занимающихся мониторингом Интернета, к 2023 году более 90% всех HTTPS-соединений в мире использовали TLS 1.3.

В России поддержка TLS 1.3 реализована в большинстве крупных веб-сервисов, включая Яндекс, Сбербанк, Mail.ru и другие. Однако внедрение может быть ограничено требованиями законодательства о криптографии: некоторые организации обязаны использовать сертифицированные средства криптографической защиты информации (СКЗИ), которые могут не поддерживать TLS 1.3 или поддерживать его с задержкой.

¶Критика и ограничения

Несмотря на улучшения, TLS 1.3 подвергался критике по нескольким направлениям:

• Сложность реализации 0-RTT: риск повторной отправки данных требует от разработчиков дополнительных мер (например, использование одноразовых токенов).
• Проблемы с прокси-серверами: корпоративные и государственные системы фильтрации трафика (например, DPI — глубокий анализ пакетов) не могут анализировать содержимое зашифрованных соединений TLS 1.3, что создаёт проблемы для соблюдения законодательства в некоторых странах, включая Россию (ФЗ-152 о персональных данных, ФЗ-398 о суверенном Интернете). В ответ на это в России разрабатываются альтернативные решения, такие как использование национальных криптографических стандартов (ГОСТ 28147-89, ГОСТ Р 34.10-2012) в рамках протокола TLS (проект «КриптоПро TLS»).
• Отсутствие обратной совместимости: TLS 1.3 не поддерживает старые версии протокола, поэтому для работы с устаревшими серверами требуется отдельная настройка (fallback на TLS 1.2).

¶Интересные факты

• TLS 1.3 стал первым протоколом семейства TLS, который был разработан с учётом опыта атак на предыдущие версии, а не путём постепенного добавления новых функций.
• Стандартизация TLS 1.3 заняла около 5 лет из-за активных дебатов в рабочей группе IETF, в частности по поводу включения 0-RTT и выбора алгоритмов.
• В 2019 году протокол TLS 1.3 был включён в список обязательных для поддержки в федеральных информационных системах США (стандарт NIST SP 800-52 Rev. 2).

¶Источники

• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 (IETF, 2018)
• «SSL/TLS: The Definitive Guide» — Ivan Ristić (2019)
• Материалы рабочей группы IETF TLS (datatracker.ietf.org/wg/tls)
• «TLS 1.3: A Modern Protocol for Secure Communication» — Cloudflare Blog (2018)
• «Криптографические протоколы: TLS 1.3» — лекции МФТИ (2020)