TLS 1.3
Название	Transport Layer Security v.1.3
Уровень (помодели OSI)	Сеансовый
Семейство	TLS
Создан в	Март 2018
Назначение протокола	Защита передачи данных
Спецификация	RFC 8446
Основные реализации (клиенты)	Mozilla Firefox иGoogle Chrome

TLS 1.3 — версия протокола защиты транспортного уровня (англ. Transport Layer Security)^[1], являющаяся седьмой итерацией протоколаTLS и его предшественникаSSL (англ. Secure Sockets Layer). Протокол предназначен для защиты передаваемых данных между узлами сети, а именно предоставление шифрования, аутентификации и целостности соединения.

Версия 1.3 была утверждена в качестве стандарта 9 августа 2018 годаИнженерным советом Интернета (англ. Internet Engineering Task Force, IETF)^[2][3].

Процедура установки соединения также называется фазой рукопожатия (англ. Handshake)^[4]. Данная процедура была модифицирована в версии 1.3 и значительно сократила время работы.TLS 1.3 необходима только одна передача в оба конца для установки соединения. В новой версииTLS 1.3 количество переговоров между клиентом и сервером сократилось с четырёх до двух, обмен ключами и схема цифровой подписи через расширение больше не требуются.

Также вTLS 1.3 была включена система рукопожатий0-RTT, которая требует ноль циклов для установки соединения . Клиент имеет возможность подключиться к уже посещённому серверу ещё до разрешения отTLS 1.3 обмена данными. Это происходит путём хранения секретной информации, такой как идентификатор сеанса или билеты предыдущих сеансов. Данная система имеет несколько недостатков в безопасности, о которых рассказано в соответствующем разделе.

• Клиент посылает сообщениеClientHello, состоящее из:^[5]
  1. Открытый ключ клиентаkey_share, полученный по протоколуДиффи-Хеллмана или идентификаторы секретных ключейpre_shared_key, если используется шифрование по заранее заданному секретному ключу, известному обоим узлам сети;
  2. Предполагаемый режим обмена секретными ключамиpsk_key_exchange_modes;
  3. Модель алгоритма цифровой подписиsignature_algorithms.
• Сервер отвечает следующими сообщениями:
  1. Ответная часть открытого ключаkey_share или выбранный идентификатор секретного ключаpre_shared_key;
  2. Серверное сообщениеEncryptedExtensions для передачи в зашифрованном виде дополнения, включающие в себя параметры тонкой настройки;
  3. При необходимости аутентификации, серверное сообщениеCertificateRequest для получения клиентского сертификата;
  4. Сертификат сервераCertificate
  5. СообщениеCertificate_verify, которое содержит цифровой сертификат сервера;
  6. Сообщение о завершении процедуры рукопожатияFinished
• Клиент проверяет сертификат сервера, генерирует итоговый секретный ключ (в случае выбора данного способа генерации) и отправляет сообщения:
  1. Сообщение о завершении процедуры рукопожатияFinished (формальная отправка для подтверждения);
  2. В случае запроса клиентского сертификата отправляет свой сертификатCertificate;
  3. Зашифрованное сообщение (с этого момента происходит шифрование данных).

• Узлы при первой возможности переходят к зашифрованному виду и практически все сообщения в Handshake получаются зашифрованными;
• Добавлено серверное сообщениеEncrypted Extensions, включающее в себя дополнительные параметры в зашифрованном виде^[6];
• Экономия целого полного цикла общения клиента и сервера и как следствие уменьшение времени работы процедуры минимум на 100 миллисекунд.

ВTLS 1.3 были удалены устаревшие и небезопасные функции, которые присутствовали в предыдущих версиях, такие как:

• Алгоритмы шифрованияDES и3DES;
• Алгоритмы хэшированияMD5 иSHA-1;
• Export-шифры и шифрRC4;
• Блочный шифрAES в режиме CBC (Cipher Block Chaining).

В новой версииTLS было реализовано свойствоPerfect Forward Secrecy, дающее гарантиюнекомпрометациисеансового ключа без обязательного обмена ключами протоколомRSA^[7][8]. Уменьшена потенциальная вероятность неправильной настройки протокола из-за его упрощения с точки зрения администрирования. Как писалось ранее, общение межу узлами сети почти сразу происходит в зашифрованном виде, благодаря чему увеличивается криптонадежность протокола^[9].

Кроме этого, в новой версии поддерживается протокол шифрованияHCDH и может не затрагивать протокол обмена ключами на основе протоколаDH.

В новой версии протокола исправлено большинство недостатков и уязвимостей предыдущих версий, однако на данный момент обнаружено несколько уязвимостей в безопасности:

1. Существует несколько проблем безопасности в сеансах возобновления0-RTT:
   • Отсутствие полной прямой секретности. То есть в случае компрометации ключей сеанса, злоумышленник может расшифровать данные0-RTT, отправленные клиентом на первом этапе. Данная проблема решается постоянным изменением ключей сеанса^[10].
   • Отсутствие гарантии запрета повторного подключения. Если злоумышленнику каким-то образом удастся завладеть вашими зашифрованными данными0-RTT, он может обмануть сервер и заставить его поверить в то, что запрос пришёл с сервера, поскольку у него нет возможности узнать, откуда пришли данные. Отправка подобных запросов несколько раз называетсяатака повторного воспроизведения.
2. Неполный отказ от RSA, из-за которого появляется возможность скомпрометировать обмен ключами через утекающиепроцессорные кэши. Данная уязвимость была использована для проведения новой вариации атакиБлейхенбахера, которая была изложена группой специалистов встатье.
3. Уязвимость при работе с функционаломURL программного обеспеченияCisco Firepower Threat Defense. Злоумышленник может без прохождения проверки подлинности обойти блокировку трафика для определённыхURL-адресов^[11]. Злоумышленник может воспользоваться этой уязвимостью, отправив созданные подключенияTLS 1.3 на уязвимое устройство. Успешныйэксплойт может позволить злоумышленнику обойти защитуTLS 1.3 и получить доступ кURL-адресам, которые находятся за пределами уязвимого устройства. Уязвимость вызвана логичной ошибкой обработкиSnort-соединений в протоколеTLS 1.3.
4. Зачастую оба узла соединения поддерживают старую версиюTLS с набором шифров, поддерживающим обмен ключамиRSA. Используя этот факт, злоумышленник может внедрить вредоносныйJavaScript файл в браузер клиента через вредоносную точку доступа по типуWi-Fi. Внедрённый файл создаёт специальныйHTTPS-запрос, включающий в себя обход посредника для прослушиваниязашифрованных данных^[12]. Данная уязвимость даёт возможность проведениякриптографических атакZombie POODLE иGOLDENDOODLE Attack^[12].

В версииTLS 1.3 набор шифров (Cipher Suites) был существенно уменьшен по сравнению с версиейTLS 1.2 и принадлежит классу шифровAEAD^[13]. Данные наборы регистрируются и хранятся в специальном реестре TLS IANA^[14], в котором присваивается уникальный идентификационные номер. Из-за этого у протокола версии 1.3отсутствует обратная совместимость с более ранними версиями даже при использовании одинаковых наборов шифров^[15].

Доступные наборы шифров дляTLS 1.3:

• TLS_AES_128_CCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_8_SHA256

На данный момент протокол TLS 1.3 поддерживается следующими браузерами и версиями^[16]:

• E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3 //IETF Datatracker. — 2018. — 1 August. —ISSN2070-1721.
• Александр Венедюхин,Ключи, шифры, сообщения: как работает TLS (Техническое описание TLS), 04/09/2015
• Benjamin Dowling, Marc Fischlin, Felix Günther, Douglas Stebila. A Cryptographic Analysis of the TLS 1.3 Handshake Protocol //Cryptology ePrint Archive. — 2021. — 22 February.
• Taking Transport Layer Security (TLS) to the next level with TLS 1.3
• Patrick Nohe. TLS 1.3: A Complete Overview (англ.) (16 июля 2019).

• Появились в 2018 году
• Криптографические протоколы
• Стандарты Интернета
• Интернет-протоколы
• Электронная коммерция

• Википедия:Cite web (не указан язык)
• Страницы, использующие волшебные ссылки RFC
• Википедия:Статьи с вики-разметкой в изображении карточки
• ПРО:ИТ:Статьи по алфавиту
• ПРО:ИТ:Последняя правка: в прошлом году