TLS 1.3 получил статус предложенного стандарта

Как сообщает opennet.ru комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, утвердил финальный вариант спецификации, определяющей протокол TLS 1.3, в качестве "Предложенного стандарта" (Proposed Standard). Занимающиеся развитием протокола TLS участники рабочей группы (Transport Layer Security Working Group) смогли прийти к консенсусу и проголосовали за стандартизацию 28 черновика спецификации (все проголосовали "За", исключая Warren Kumari из Google, который проголосовал "не возражаю", пояснив, что не является экспертом по обсуждаемому вопросу). Установка защищенных соединений с использованием TLS 1.3 уже поддерживается в Firefox и Chrome, и будет предложена в ветке OpenSSL 1.1.1.

Особенности TLS 1.3:

• Удаление устаревших и ненадежных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, не-AEAD шифры, статический обмен ключами RSA и DH, указание unix-времени в Hello-сообщениях и т. п.);
• Работа только в режиме совершенной прямой секретности (PFS, Perfect Forward Secrecy), при котором компрометация одного из долговременных ключей не позволяет расшифровать ранее перехваченный сеанс. Оставление поддержки только PFS вызвало много споров и стало камнем преткновения в достижении консенсуса, так как ряд производителей указывали на возможное негативное влияние PFS на корпоративные системы, в локальных сетях которых применяется инспектирование проходящего трафика, например, для обеспечения отказоустойчивости, мониторинга, диагностики проблем, фильтрации вредоносного ПО и выявления атак.
• Сокращение числа шагов при согласованиии соединения и поддержка режима 0-RTT для устранения задержек при возобновлении ранее установленных HTTPS-соединений. При установке HTTPS-соединения выполняются 4 фазы: запрос DNS, TCP Handshake (1 RTT), TLS Handshake (2 RTT на согласование ключей и параметров шифрованного канала) и отправка запроса HTTP (1 RTT). По сравнению с TLS 1.2 в новом стандарте число RTT для TLS Handshake сокращено с 2 до 1, т. е. для установки и возобновления соединения требуется запрос DNS и 3 цикла обмена данными (RTT) вместо 4. 0-RTT позволяет сохранить ранее согласованные параметры TLS и снизить до 2 число RTT при возобновлении ранее установленного соединения;
• Поддержка потокового шифра ChaCha20 и алгоритма аутентификации сообщений (MAC) Poly1305, разработанных Дэниелом Бернштейном (Daniel J. Bernstein), Таней Ланге (Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 можно рассматривать, как более быстрые и безопасные аналоги AES-256-CTR и HMAC, программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальных аппаратных ускорителей;
• Поддержка защищенных ключей аутентификации на основе цифровых подписей Ed25519, которые обладают более высоким уровнем безопасности, чем ECDSA и DSA, и при этом отличаются очень высокой скоростью верификации и создания подписей. Стойкость к взлому для Ed25519 составляет порядка 2^128 (в среднем для атаки на Ed25519 потребуется совершить 2^140 битовых операций), что соответствует стойкости таких алгоритмов, как NIST P-256 и RSA с размером ключа в 3000 бит или 128-битному блочному шифру. Ed25519 также не подвержен проблемам с коллизиями в хэшах, не чувствителен к атакам через определение скорости работы кэша (cache-timing attacks) и атакам по сторонним каналам (side-channel attacks);
• Поддержка обмена ключами на основе алгоритмов x25519 (RFC 7748) и x448 (RFC 8031);
• Поддержка HKDF (HMAC-based Extract-and-Expand Key Derivation Function).