Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил (https://blog.mozilla.org/security/2018/08/13/tls-1-3-publish.../) формирование RFC для протокола TLS 1.3 и опубликовал (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/) связанную с ним спецификацию под идентификатором RFC 8446 (https://tools.ietf.org/html/rfc8446). RFC получил статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний.
Установка защищённых соединений с использованием TLS 1.3 уже поддерживается в Firefox и Chrome, и реализована в ветке OpenSSL 1.1.1 (https://www.opennet.dev/opennews/art.shtml?num=48074), которая пока находится на стадии тестирования. О включении поддержки TLS 1.3 на своих серверах заявили компании Cloudflare, Google и Facebook. Facebook отмечает (https://code.fb.com/networking-traffic/deploying-tls-1-3-at-.../), что уже около 50% всего трафика к социальной сети обрабатывается с использованием TLS 1.3.
Особенности TLS 1.3:
- Работа только в режиме совершенной прямой секретности (PFS, Perfect Forward Secrecy (https://ru.wikipedia.org/wiki/Perfect_forward_secrecy)), при котором компрометация одного из долговременных ключей не позволяет расшифровать ранее перехваченный сеанс. Оставление поддержки только PFS вызвало много споров (https://www.opennet.dev/opennews/art.shtml?num=46902) и стало камнем преткновения в достижении консенсуса, так как ряд производителей указывали на возможное негативное влияние PFS на корпоративные системы, в локальных сетях которых применяется (https://www.ietf.org/mail-archive/web/tls/current/msg21275.html) инспектирование проходящего трафика, например, для обеспечения отказоустойчивости, мониторинга, диагностики проблем, фильтрации вредоносного ПО и выявления атак;
- Сокращение числа шагов при согласованиии соединения и поддержка режима 0-RTT (https://blog.cloudflare.com/introducing-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 при возобновлении ранее установленного соединения. По данным (https://code.fb.com/networking-traffic/deploying-tls-1-3-at-.../) Facebook, по сравнению с TLS 1.2 использование TLS 1.3 приводит к сокращению задержек на 46% при установке соединений и на 10% при отправке первого запроса;
- Поддержка потокового шифра ChaCha20 (http://cr.yp.to/chacha.html) и алгоритма аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), разработанных Дэниелом Бернштейном (Daniel J. Bernstein (http://cr.yp.to/djb.html)), Таней Ланге (Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 можно рассматривать, как более быстрые и безопасные аналоги AES-256-CTR и HMAC, программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальных аппаратных ускорителей;
- Поддержка защищённых ключей аутентификации на основе цифровых подписей Ed25519 (http://ed25519.cr.yp.to/), которые обладают более высоким уровнем безопасности, чем ECDSA и DSA, и при этом отличаются очень высокой скоростью верификации и создания подписей. Стойкость к взлому для Ed25519 составляет порядка 2^128 (в среднем для атаки на Ed25519 потребуется совершить 2^140 битовых операций), что соответствует стойкости таких алгоритмов, как NIST P-256 и RSA с размером ключа в 3000 бит или 128-битному блочному шифру. Ed25519 также не подвержен проблемам с коллизиями в хэшах, не чувствителен к атакам через определение скорости работы кэша (cache-timing attacks (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf)) и атакам по сторонним каналам (side-channel attacks);
- Поддержка обмена ключами на основе алгоритмов x25519 (https://en.wikipedia.org/wiki/Curve25519) (RFC 7748 (https://tools.ietf.org/html/rfc7748)) и x448 (RFC 8031 (https://tools.ietf.org/html/rfc8031));
- Поддержка HKDF (https://en.wikipedia.org/wiki/HKDF) (HMAC-based Extract-and-Expand Key Derivation Function);
- Удаление устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, не-AEAD шифры, статический обмен ключами RSA и DH, указание unix-времени в Hello-сообщениях и т.п.).
URL: https://blog.mozilla.org/security/2018/08/13/tls-1-3-publish.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=49126
Вариант для распечатки
