Комитет 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.ru/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.ru/opennews/art.shtml?num=46902) и стало камнем преткновения в достижении консенсуса, так как ряд производителей указывали на возможное негативное влияние PFS на корпоративные системы, в локальных сетях которых применяется (https://www.ietf.org/mail-archive/web/tls/current/msg21275.h... инспектирование проходящего трафика, например, для обеспечения отказоустойчивости, мониторинга, диагностики проблем, фильтрации вредоносного ПО и выявления атак;
- Сокращение числа шагов при согласованиии соединения и поддержка режима 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.ru/opennews/art.shtml?num=49126
Все уже перешли на 1.3 ? Какие подводные камни?
Для обычного человека - никаких :) Если вдруг зайдешь на Google используя Chrome[um] то ты уже TLS 1.3 испоьзуешь... CTRL+SHIFT+I -> Security
Сложна. В Firefox можно нажать на значок замка и посмотреть всю информацию о сертификате и шифровании. Почему в хроме так всё плохо?
> Почему в хроме так всё плохо?потому что домохозяйкам это не нужно
Хром вместо пользователя решает вопросы сертификатов. И двумя версиями выше (Crome Canary) уже новые требования к сертификатам.. уже не все сайты могу открыть. В их числе даже olxТак вот, не нужна тебе инфа о сертификате, если ты используешь браузер который силой пропихивают ssl, ещё и самый новый и самый молодежный
Нужно переходить на божественный FF Quantum.
>уже новые требования к сертификатам.. уже не все сайты могу открыть.Не сказал бы, что это плюс.
Хром сливает данные и торгует пользователями.
Канары вполне открывает olx. Я им часто пользуюсь
> Connection - secure (strong QUIC)Чет не нашел я там ничего про TLS.
>> Connection - secure (strong QUIC)
> Чет не нашел я там ничего про TLS.есть ж
"Secure Connection
The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and a strong cipher (AES_128_GCM)."
59.0.3054.0
> Connection - secure (strong QUIC)
> The connection to this site is encrypted and authenticated using QUIC (a strong protocol), X25519 (a strong key exchange), and AES_128_GCM (a strong cipher).Нет ж
68.0.3440.106
Хотя, если в flags запретить QUIC, то станет TLS 1.3
Чето я тебя не понел.
>Если вдруг зайдешь на Google используя Chrome[um]...Спасибо, конеш, братуха, но каким образом это коррелирует с моим вопросом? Я про серваки спрашиваю.
Скомпилируй OpenSSL 1.1.1 и вперёд.
> Скомпилируй OpenSSL 1.1.1 и вперёд.Вперед!
Плохо прослушивается. Надо бы ослабить шифрование для гос. лиц.
Encrypted SNI враги народа таки задавили?
Удивительно что PFS не задавили.
его никто и не планировал в 1.3
это пока вообще черновой проект, который не факт что в принципе доживет до поддержки хотя бы одной парой браузер-сервер.в отличие от tls1.3,который уже де-факто навязан всем.
Обратная совместимость друг копирастов и АНБ.
Ты сморозил хрень. Покайся.
> Ты сморозил хрень. Покайся.Товарищ майор залогинся.