The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Опубликован RFC для TLS 1.3"
Отправлено opennews, 13-Авг-18 20:58 
Комитет 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

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру