The OpenNET Project / Index page

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

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

24.03.2018 12:15

Комитет 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).


  1. Главная ссылка к новости (http://www.ietf.org/mail-archi...)
  2. OpenNews: Адресация скрытых сервисов Tor переведена в категорию интернет-стандарта
  3. OpenNews: Новый метод атаки на TLS, затрагивающий 27 из 100 крупнейших сайтов
  4. OpenNews: Дебаты вокруг TLS 1.3 и совершенной прямой секретности
  5. OpenNews: В Firefox 52 планируют по умолчанию включить поддержку TLS 1.3
  6. OpenNews: Опубликован первый черновик стандарта Strict Transport Security для SMTP
Лицензия: CC-BY
Тип: Интересно / К сведению
Ключевые слова: tls
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Вы забыли заполнить поле Name (?), 12:59, 24/03/2018 [ответить] [показать ветку] [···]    [к модератору]
  • +3 +/
    > все проголосовали "За", исключая Warren Kumari из Google, который проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу

    Как можно быть в рабочей группе и не являться "экспертом"?

     
     
  • 2.2, lucentcode (ok), 13:09, 24/03/2018 [^] [ответить]    [к модератору]
  • +9 +/
    >> все проголосовали "За", исключая Warren Kumari из Google, который проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу
    > Как можно быть в рабочей группе и не являться "экспертом"?

    Да запросто - если это лоббист крупной компании. Его прикрепили к комитету что-бы он транслировал пожелания компании членам комитета, а их фидбек - руководству и более осведомлённым в данном вопросе коллегам. Сам он при этом круто разбирается в DNSSEC, если верить его профилю. Вероятно и в криптографии он всё-таки разбирается, просто TLS не его профиль.


     
  • 2.5, Аноним (-), 13:42, 24/03/2018 [^] [ответить]    [к модератору]
  • +20 +/
    Например, можно быть специалистам по сетевым протоколам, но при этом не разбираться в деталях криптографии.
     
  • 2.22, пох (?), 09:44, 25/03/2018 [^] [ответить]     [к модератору]
  • –3 +/
    правильный вопрос - как можно быть представителем гугля и настолько честным пол... весь текст скрыт [показать]
     
  • 2.33, Брюс Шнайер (?), 18:56, 26/03/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    > проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу

    Знаем мы это, называется: "Не виноватая я, он сам пришел!..", - заранее якорь ставит.
    Значит, гугл пропихнул очередной гнилой стандарт и делает невинную мину при плохой игре.

     
  • 1.4, Retrosharer (?), 13:25, 24/03/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –2 +/
    > совершенной прямой секретности

    Совершенная секретность с упреждением!
    Но лучше - совершенная приватность с упреждением

     
     
  • 2.6, Crazy Alex (ok), 13:47, 24/03/2018 [^] [ответить]    [к модератору]  
  • +/
    Лучше калька - кто на русском всё это осваивает - привыкнет, а кто знает на английском (а их, понятно, большинство) - сразу поймёт.
     
  • 2.9, Аноним (-), 16:01, 24/03/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Совершенно секретный Retrosharer.
     
  • 2.10, Ordu (ok), 16:29, 24/03/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > Но лучше - совершенная приватность с упреждением

    Лучше не надо. Есть слово privacy, которое естественным образом "переводится" как приватность, если переводить secrecy как "приватность", то могут возникнуть трудности с пониманием перевода.

     
  • 2.21, Ю.Т. (?), 09:41, 25/03/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Эти слова даже по-английски трудноразличимы, и практически различаются только по употреблению. Два пути: (фактический) транскрипция и (трудный) перевод по смыслу.

    Ради пояснения токмо:
    secrecy - тайность
    privacy - укрытость, скрытость (лица от мира)

     
  • 1.12, X4asd (ok), 17:22, 24/03/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    > RSA с размером ключа в 375 байт

    чего?

     
     
  • 2.14, Аноним84701 (ok), 17:59, 24/03/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    http://ed25519.cr.yp.to/
    > breaking it has similar difficulty to breaking NIST P-256, RSA with ~3000-bit keys, strong 128-bit block ciphers

    Кто-то немного переусердствовал при переводе :)
    Закомитил поправку.

     
  • 1.13, Слава (??), 17:52, 24/03/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Господа, а можно вопросы:
    1) Действительно ли  AES-256-CTR и HMAC можно считать небезопасными/медленными, раз вместо этих примитивов предлагается использовать новые?
    2) Насколько ускорится соединение TLS, при сокращении TLS Handshake с 2 до 1?
    3) "Поддержка защищённых ключей аутентификации Ed25519, которые обладают более высоким уровнем безопасности, чем ECDSA и DSA" - опять же, ECDSA уже взломали? Есть теории?
    4) Поддержка x25519 (RFC 7748) и x448 (RFC 8031), зачем? Чтобы было или реально польза?
    5) HKDF так необходима как и PBKDF?
    Спасибо!
     
     
  • 2.15, Сергей (??), 19:11, 24/03/2018 [^] [ответить]    [к модератору]  
  • +16 +/
    1) Никто не говорил что AES-CTR/HMAC не безопасны. Просто не нужно использовать по отдельности два примитива: шифрование и аутентификацию. Они должны быть всегда вместе и поэтому TLS 1.3 говорит что используются только AEAD режимы (аутентифицированного шифрования). Как минимум AES-CTR/HMAC медленный и не имеет его использовать когда есть AES-CCM, AES-GCM или ChaCha20-Poly1305.
    2) Достаточно сделать ping чтобы увидеть время одного round-trip-а чтобы увидеть насколько ускорится соединение.
    3) 25519 как минимум не требует подкармливанием энтропии во время формирования подписи. Это убирает множество возможных атак. 25519 кривую существенно проще реализовать правильно, без диких side-channel утечек. ECDSA/DSA можно использовать безопасно -- но сложно и лучше не связываться. https://safecurves.cr.yp.to/
    4) 25519/448: снова советую посмотреть ссылку из предыдущего пункта про safecurves. Они безопаснее. Плюс 25519 существенно более быстрый на практике. Реально польза которую пользователи жаждят.
    5) HKDF хорошая проверенная простая функция вовсю используемая за пределами TLS. TLS-PRF используемый раньше просто бесмысленнен. HKDF это более простая реализация. Упоминание PBKDF я не нашёл в TLS 1.3.
     
     
  • 3.17, Слава (??), 20:14, 24/03/2018 [^] [ответить]    [к модератору]  
  • +/
    Сергей, спасибо за развернутые ответы, оч помогли. К сожалению, могу оставить вам только веселый смайл (o^▽^o) :)
     
  • 2.16, h31 (ok), 20:13, 24/03/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    Добавлю своё мнение к предыдущему комментатору.
    1) Они безопасные, но при реализации этих алгоритмов есть много мест, где можно накосячить (особенно если говорить про режим CBC). В этом плане AEAD делает жизнь проще для авторов библиотек шифрования. По скорости они хороши, но если есть аппаратное ускорение AES, то AES-GCM будет быстрее. А если его нет, то предлагается использовать ChaCha20.
     
     
  • 3.18, h31 (ok), 20:16, 24/03/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    Конкретно AES-CTR тут особых проблем не вызывает, народ больше хотел отказаться от AES-CBC. CTR просто оказался не очень популярен, народ довольно быстро перескочил на GCM (который по своей сути CTR + MAC на основе AES).
     
  • 2.23, пох (?), 10:00, 25/03/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    > 1) Действительно ли  AES-256-CTR и HMAC можно считать небезопасными/медленными, раз вместо

    нет.
    NIH.

    > 2) Насколько ускорится соединение TLS, при сокращении TLS Handshake с 2 до

    соединение - как и написано, в два раза.
    Скорость открытия страницы твоим браузером - нинасколько, она не этим вообще ограничена.

    > 3) "Поддержка защищённых ключей аутентификации Ed25519, которые обладают более высоким
    > уровнем безопасности, чем ECDSA и DSA" - опять же, ECDSA уже
    > взломали? Есть теории?

    NIH, причем НЕТ ни одного подтвержденного независимыми экспертами исследования протоколов и алгоритмов djb. Даже экспертами NSA. Все просто ему и компании поверили.

    > 4) Поддержка x25519 (RFC 7748) и x448 (RFC 8031), зачем?

    это просто спецификация эллиптических кривых - в смысле, инструкция для программиста, как их считать. Учитывая что от nist'овских "из трубки что-то жареным потянуло" еще в 2010м, нужны хоть какие-то.

    > 5) HKDF так необходима как и PBKDF?

    вместо. Опять же потому, что ко всему, что наразрабатывала RSA, "есть вопросы" (на самом деле нет, хотя выглядит этот алгоритм для типового применения просто на порядок лучше - но я тоже не эксперт, как тот Кумар, и возможно эта простота с полаганием на чужие данные может выйти боком)

     
  • 1.19, ктота (?), 03:18, 25/03/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    "RTFM Inf." а с таким названием точно пропустят?
     
  • 1.20, barmaglot (??), 05:27, 25/03/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Поправьте: Ed25519 - это система цифровых подписей. А "система аутентификации", на самом деле протокол аутентификации это curve25519, стандартизован как  x25519. Разработаны также Бернштейном.

    Как мы долго этого ждали. Наконец-то !!!!!

     
  • 1.24, Аноним (-), 11:25, 25/03/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    Ребят, можете написать криптография для dummies Вот, например, Poly1305 это в... весь текст скрыт [показать]
     
     
  • 2.25, Сергей (??), 11:44, 25/03/2018 [^] [ответить]     [к модератору]  
  • +5 +/
    MAC функция принимает на входе ключ и сообщение На выходе выдаёт аутентификацио... весь текст скрыт [показать]
     
  • 1.26, Аноним (-), 13:06, 25/03/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    Есть сообщение M, которое необходимо передать Есть секретный ключ K, о котором ... весь текст скрыт [показать]
     
     
  • 2.27, Сергей (??), 13:27, 25/03/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Всё верно описали. Одно но, придирка: лучше вычислять MAC над шифротекстом, а не открытым текстом. Когда-то TLS делал как вы и описали и это приводило к возможным атакам типа BEAST, позволяющим полностью дешифровать сообщение.

    > К сожалению, я пока не понял как работает Диффи-Хельман, пресловутая цифровая подпись
    > документа, https (или понял, потому что схема описанная выше очень сильно
    > напоминает обмен браузера со Сбером) и электронная почта с PGP.

    Конкретику работы DH или ЭЦП лучше погуглить о том как они устроены -- там много разновидностей. HTTPS фактически вы описали (ну, одно из подмножеств, так как в TLS тоже уйма всяких режимов работы).

    PGP: симметричная часть схожая, хотя вместо MAC там используется просто хэш, находящийся внутри сообщения которое подписывается ЭЦП (это архаично, но и PGP в таком виде был создан чуть ли не четверть века назад). Диффи-Хельман там не применяется, а вместо него действительно асимметричное шифрование. Но суть схожая: шифр, какая-то аутентификация зашифрованного сообщения, асимметричная подпись для аутентификации собеседника, асимметричное шифрование для передачи симметричных ключей. Сейчас обсуждается и скоро должен увидеть свет новый стандарт OpenPGP -- в нём уже всё точно так же как и в TLS 1.3: *25519, AEAD (шифр и MAC вместе) режимы шифрования и всё по-современному.

     
  • 1.28, Аноним (-), 13:59, 25/03/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • –1 +/
    Может прокомментируете коротко https ru wikipedia org wiki D0 AD D0 BB D0 B5... весь текст скрыт [показать]
     
     
  • 2.29, Сергей (??), 14:25, 25/03/2018 [^] [ответить]     [к модератору]  
  • +2 +/
    Для объяснения на пальцах действительно часто применяют понятие расшифровки для... весь текст скрыт [показать]
     
     
  • 3.30, Аноним (-), 20:19, 25/03/2018 [^] [ответить]     [к модератору]  
  • +/
    Есть отправитель с ключами Priv и Pub, который передаёт сообщение M 1 Функция ... весь текст скрыт [показать]
     
     
  • 4.31, Сергей (??), 21:56, 25/03/2018 [^] [ответить]    [к модератору]  
  • +/
    > Это и есть так называемая цепочка доверия в системах PKI?

    В принципе да, всё верно описали.

    > Кажется я уже начинаю понимать, можно не шифровать сам файл, а допустим его хэш

    Да, подписываются всегда хэши. Особенность большинства асимметричных функций подписи (или шифрования) -- они не могут работать с сообщениями больше размера своего ключа, грубо говоря. То есть могут подписать только 256 или там например 512 бит.

    > Тут меня смущает аналогия с обыкновенной подписью - цифровая подпись каждый раз
    > разная для разных файлов. Куда больше на цифровой аналог рукописной подписи
    > подходят именно приватные ключи

    Подпись настоящая тоже разная: всегда что-то меняется при написании, но написать всё-равно сможете только вы. Ваше умение -- ваш приватный ключ. Плюс не забывайте что материальная подпись ставится на каком-то материальном носителе, чернила наносятся поверх какого-то текста, какого-то листка. В цифровой приватный ключ применяется к чётко заданному (по хэшу) набору данных.

    На правах саморекламы могу посоветовать вот такое видео небольшое: https://www.youtube.com/watch?v=Apl9QzuXUz8

     
  • 1.34, Ne01eX (ok), 16:57, 27/03/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Ну в gnutls с TLS 1.3 всё в порядке, вроде...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


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