Rfc 5246 как включить

Как включить поддержку TLS 1.3 в Firefox и Chrome

Следующее руководство содержит инструкции по включению поддержки TLS 1.3 (Transport Layer Security) в Mozilla Firefox и Google Chrome.

Transport Layer Security, сокращенно TLS, представляет собой криптографический протокол для безопасного обмена данными по компьютерной сети. Текущая версия TLS — 1.2, а TLS 1.3 доступен в качестве окончательной версии.

TLS 1.3 основан на TLS 1.2, но предлагает значительное улучшение безопасности и конфиденциальности по сравнению с протоколом, который в настоящее время веб-браузеры поддерживают по умолчанию.

Хотя перечислять все улучшения было бы слишком далеко, вы можете проверить Википедия запись на TLS 1.3 для этого удаляет поддержку некоторых криптографических хэш-функций и именованных эллиптических кривых, запрещает использование небезопасных согласований SSL или RC4 или поддерживает новый потоковый шифр, протоколы обмена ключами или алгоритмы цифровой подписи. Он также быстрее, чем TLS 1.2, за счет уменьшения количества циклов приема-передачи до 1 по сравнению с TLS 1.2, использующего 2 приема-передачи.

Включите поддержку TLS 1.3 в Firefox и Chrome

И Firefox, и Chrome поддерживают TLS 1.3, но версия Transport Layer Security не включена по умолчанию. Основная причина этого, вероятно, в том, что он пока доступен только как черновик.

Обновить : Опубликована финальная версия TLS 1.3..

Тестирование возможностей TLS вашего браузера

Первое, что вы можете сделать, это проверить, какие протоколы TLS и SSL поддерживает ваш браузер.

Один из лучших вариантов проверить возможности — посетить SSL Labs, где «Мой клиент» страница, проверяющая возможности браузера.

Он раскрывает все протоколы, поддерживаемые браузером, проверяет, уязвим ли браузер для определенных известных атак, перечисляет поддерживаемые наборы шифров, сведения о протоколе и то, как браузер обрабатывает смешанный контент.

Если вы запустите тест с помощью Chrome или Firefox Stable прямо сейчас, вы получите ответ «нет» рядом с TLS 1.3.

Включить TLS 1.3 в Firefox

Все последние версии Mozilla Firefox уже поддерживают TLS 1.3. Пользователи должны были настроить максимальную поддерживаемую версию ранее на about: config, чтобы добавить поддержку, но в этом больше нет необходимости.

Тем не менее, вот способ убедиться, что TLS 1.3 поддерживается:

1. Загрузите about: config в адресную строку Firefox. Подтвердите, что вы будете осторожны, если появится экран предупреждения. Откроется редактор конфигурации Firefox.
2. Найдите security.tls.version.max.
3. Измените значение предпочтения на 4, дважды щелкнув по нему.

Включить TLS 1.3 в Chrome

Google Chrome также поддерживает TLS 1.3 по умолчанию. Google недавно изменил флаг, который обрабатывает TLS. В настоящее время можно только выбрать разные версии TLS или отключить его.

Вероятно, что Google уберет эту опцию в ближайшем будущем, когда запустит поддержку финальной версии TLS 1.3.

Обратите внимание, что некоторые браузеры на основе Chromium, такие как Vivaldi, поддерживают этот же флаг. Вы также можете применить изменения к этим браузерам.

1. Загрузите chrome: // flags / в адресную строку браузера. Откроется страница экспериментов в веб-браузере.
2. Найдите включенную максимальную версию TLS. Вы также можете напрямую перейти по этой ссылке: chrome: // flags / # tls13-variant
3. Вы можете отключить эту функцию или выбрать одну из поддерживаемых версий.
4. Перезапустите веб-браузер.

Вывод

Некоторые сайты, например Cloudflare например, уже поддерживает TLS 1.3. Клиенты Cloudflare могут включить TLS 1.3 для своих сайтов, чтобы «повысить скорость и безопасность пользователей Интернета во всем мире».

Смотрите так же:

1. Включить единый режим просмотра для всех папок в проводнике Windows
2. Создание собственных сочетаний клавиш для вашего компьютера с Windows
3. Назад к основам: резервное копирование реестра
4. 40 лет жизни и преступности в музыкальном бизнесе

Как включить TLS 1.3 в Chrome, Safari и Firefox��⚕️

Закрытие уязвимостей

Автор cryptoparty На чтение 2 мин Опубликовано 28.09.2018

Процедура включения TLS 1.3 в ваших любимых браузерах

Используете ли вы TLS 1.3 c повышенной производительностью и безопасностью?

Типовая рабочая версия TLS 1.3 была выпущена в 2017 году и приятно видеть, что многие веб-сайты приняли это новшество.

Если вы являетесь владельцем веб-сайта, вы можете рассмотреть возможность его включения.

Ознакомьтесь с моей предыдущей статьей о том, Как включить TLS 1.3 в Nginx, Cloudflare

Но как насчет клиентских браузеров?

Chrome начиная с версии 63 и Firefox 61 начали поддерживать TLS 1.3, и если ваш браузер еще не поддерживает его, то вам не хватает функций производительности и конфиденциальности.

Включение TLS 1.3 в Chrome

• Запустите Chrome
• Введите в адресной строке следующее и нажмите Enter.

chrome://flags/#tls13-variant

Убедитесь, что он не отключен. Вы можете выбрать «Default» или «Ebnaled».

• Перезапустите Chrome

Более новые версии Chrome

• Введите “chrome://flags/” в адресной строке.
• Введите “TLS” в поле поиска.
• Установите TLS на значение «Default» или «Ebnaled».
• Перезапустите браузер.

Включение TLS 1.3 в Firefox

• Запустите Firefox
• Введите about:config в адресной строке и нажмите Enter.
• Начните вводить tls.version в поиске, и вы должны увидеть следующее:

• Убедитесь, что значение security.tls.version.max равно 4
• Если нет, дважды щелкните по нему, чтобы изменить значение 4.

Включение TLS 1.3 в Safari

• Откройте терминал и станьте рутом

• Введите следующую команду и нажмите Enter.

defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1

• Переустановите Safari

Тестирование браузера с TLS 1.3

Как вы можете гарантировать, что ваш браузер поддерживает последнюю версию TLS?

Есть несколько инструментов, которые вы можете использовать.

Просто нажмите следующую ссылку, чтобы проверить это.

Проверка безопасности браузера с помощью Cloudflare – вот как выглядит результат, когда браузер поддерживает его

How’s My SSL – проверьте совместимость протокола SSL / TLS, и известные уязвимости.

Я надеюсь, что эта краткая инструкция поможет вам включить последнюю версию TLS 1.3 в Chrome и Firefox.

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!

Добавить комментарий Отменить ответ
Станислав 20.04.2020 в 20:34

Хорошая статья. Вообще не знал о том, что таким образом можно улучшить безопасность браузера. Подключил у себя на Хроме. Еще использую Яндекс Браузер, но там TLS1.3 видимо стоит по умолчанию – во всяком случае проверка показала именно это.

Иосиф Висарионович Сталин 30.06.2020 в 13:42

насчет вот єтотй ссьілки… chrome://flags/#tls13-variant
полное вранье
ниче не работает, просто вьідает какой-то список где ни слова про TLS 1.3
и как его включить..
может из-за того что у меня виндовс виста…переустанавливал 3 раза и обнова тоже есть…
но вот сертификатьі какой-то там безопасности отстранили меня от интернета

cryptoparty автор 30.06.2020 в 14:13
андрей 30.06.2020 в 16:25
та где ж оно там есть. какой по счету пункт? сверху, снизу, сбоку .
я в упор там ниче не вижу….
cryptoparty автор 30.06.2020 в 17:09
Не поленился тебе скриншот сделать https://itsecforu.ru/wp-content/uploads/2020/06/11.png
андрей 30.06.2020 в 20:51

спасибо большое…
но оно у меня совсем не так вьіглядит,…..далеко не так
я зашел по ссьлке, которая напечатана в статье
всеравно спасибо, теперь хоть буду знать, как оно должно вьіглядеть

Деловой фронт 05.11.2022 в 15:11

нет боль_ше поддержки на новом хроме chrome://flags/#tls13-variant вот из за чего и не отображает.. Сегодня 2022 год статью удаляйте так как оно устарело и люди путаются..

cryptoparty автор 06.11.2022 в 05:24

Спасибо за совет, но как-нибудь сами решим, что удалять. Данную статью дополнили настройками на новые хромы

Поддержать нас

• Аудит ИБ (49)
• Вакансии (12)
• Закрытие уязвимостей (110)
• Книги (27)
• Мануал (2 364)
• Медиа (66)
• Мероприятия (39)
• Мошенники (23)
• Обзоры (833)
• Обход запретов (34)
• Опросы (3)
• Скрипты (116)
• Статьи (361)
• Философия (127)
• Юмор (18)

Наш Telegram

Социальные сети
Поделиться

Anything in here will be replaced on browsers that support the canvas element

• ��Создание пользователя MySQL с помощью опции GRANT 15.11.2023

В области управления базами данных привилегии пользователей являются основой безопасности и контроля доступа. MySQL, как одна из наиболее популярных реляционных систем управления базами данных, предлагает полный набор команд для управления правами пользователей, предназначенных для обеспечения целостности и конфиденциальности данных. Одним из важнейших аспектов этой системы является возможность предоставления пользователям определенных прав, включая мощную привилегию ‘GRANT […]

Переход бизнеса в Интернет открывает новые возможности для развития. Вы можете обслуживать несколько точек и работать с большой аудиторией. Однако, став известным брендом в Интернете, вы также становитесь уязвимы для многих киберпреступлений, которые совершаются угрожающими субъектами с целью получения прибыли, используя репутацию вашего бренда. Одним из таких преступлений является киберсквоттинг. Оно может привести к потере […]

В наши дни мобильные гаджеты стали неотъемлемой частью нашей жизни. Они не только предоставляют средство связи через традиционные звонки, но также открывают доступ к мессенджерам и специальным программам. Таким образом, современный человек взаимодействует с окружающим миром как через сим-карту, так и через разнообразные коммуникационные платформы. Проблемы с рекламой в социальных сетях Социальные сети стремятся ужесточить правила […]

Web Path Finder – это программа на языке Python, предоставляющая информацию о сайте. Она позволяет получить такие сведения, как заголовок страницы, дата последнего обновления, информация о DNS, поддоменах, именах брандмауэров, используемых технологиях, информация о сертификатах и многое другое. Особенности и преимущества Получение важной информации о сайте Получение информации о технологиях, используемых на сайте Определение поддоменов […]

В мире Linux права доступа и владения являются важнейшими понятиями, которые должен понимать каждый пользователь. Однако нередко при попытке изменить эти атрибуты возникают ошибки. Одной из таких ошибок является ошибка “chmod: Operation not permitted. В этой статье мы рассмотрим шаги по устранению этой ошибки. Понимание ошибки Прежде чем перейти к рассмотрению решений, необходимо разобраться в […]

Протокол безопасности транспортного уровня (TLS), версия 1.2 (RFC 5246) (Часть 1)

На настоящий момент (август 2021 года) мною не было найдено хоть сколько-нибудь приемлемого перевода стандарта протокола TLS версии 1.2 на русский язык. Единственный найденный перевод находится сайте protocols.ru и при всем уважению к его автору, не устраивает меня по причине неудобочитаемости и трудности восприятия. И хотя на сайте efim360.ru находится качественно выполненный перевод стандарта протокола TLS версии 1.3, многие места этого перевода могут вызвать некоторые трудности для понимания, особенно у начинающего изучать криптографию читателя. Для устранения таких «белых пятен» и было задумано осуществить перевод стандарта протокола TLS версии 1.2 на русский язык.

Развитием стандарта TLS занимается организация IETF (Internet Engineering Task Force). На настоящий момент протокол TLS 1.2 считается устаревшим после выхода в августе 2018 года стандарта протокола TLS 1.3. Тем не менее, спецификация протокола версии 1.2 до сих пор является наиболее распространенной версией протокола TLS, что не лишает практического смысла ее перевод на русский язык. С момента опубликования в августе 2008 года стандарта TLS 1.2 выходили другие стандарты, обновлявшие спецификацию TLS 1.2. Данные стандарты приведены в исходном тексте спецификации. Тем не менее, автор считает нужным привести их и здесь:

E. Rescorla, M. Ray, S. Dispensa, N. Oskov «Transport Layer Security (TLS) Renegotiation Indication Extension», RFC 5746, February 2010 – Устранение уязвимости во время пересогласования (англ. renegotiation) сервером и клиентом новых ключей. Описание расширения индикации пересогласования (Renegotiation Indication Extension).

M. Brown, R. Housley, «Transport Layer Security (TLS) Authorization Extensions», RFC 5878, May 2010 – Документ описывает расширения авторизации для протокола рукопожатия TLS (TLS Handshake Protocol). Расширения указываются в клиентских и серверных сообщениях «hello»[1] для подтверждения того, что обе стороны поддерживают желаемый тип авторизации данных.

S. Turner, T. Polk, «Prohibiting Secure Sockets Layer (SSL) Version 2.0», RFC 6176, March 2011 – Документ содержит требование запрета на согласование использования протокола Secure Sockets Layer (SSL) версии 2.0 при установлении соединения между сервером и клиентом.

A. Popov, «Prohibiting RC4 Cipher Suites», RFC 7465, February 2015 — Документ содержит требование запрета на согласование криптонаборов на основе потокового шифра RC4 при установлении соединения между сервером и клиентом. Документ обязателен для протокола TLS всех версий.

B. Moeller, A. Langley, «TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks», RFC 7507, April 2015 – Документ определяет сигнальное значение криптонабора (Signaling Cipher Suite Value (SCSV)), предотвращающее атаки на понижение версии протоколов TLS и DTLS (Datagram Transport Layer Security).

R. Barnes, M. Thomson, A. Pironti, A. Langley, «Deprecating Secure Sockets Layer Version 3.0», RFC 7568, June 2015 – Объявление о прекращении использования (англ. deprecating[2]) протокола Secure Sockets Layer версии 3.0 (SSLv3, SSL 3.0).

K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray, «Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension», RFC 7627, September 2015 – Спецификация определяет расширение TLS, которое контекстно связывает основной ключ[3] с полным логом протокола рукопожатия (TLS Handshake Protocol), вычисляющего этот ключ. Таким образом, предотвращается атака «man-in-the-middle», при которой злоумышленник при помощи одного основного ключа может устанавливать одновременно две сессии – одну с клиентом, другую – с сервером.

A. Langley, «A Transport Layer Security (TLS) ClientHello Padding Extension», RFC 7685, October 2015 – Документ описывает расширение протокола TLS, позволяющее увеличивать до желаемого размера (англ. to pad) сообщения ClientHello. Данная необходимость возникла в связи с тем, что некоторые реализации протокола, основанные на новых криптонаборах и расширениях, увеличивают сообщение ClientHello.

A. Langley, W. Chang, N. Mavrogiannopoulos,J. Strombergson, S. Josefsson, «ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)», RFC 7905, June 2016 – Документ описывает использование криптонабора ChaCha и аутентификатора Poly1305 в протоколах TLS и DTLS.

D. Gillmor, «Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)», RFC 7919, August 2016 – Документ водит группы ffdhe в регистр Supported Groups (поддерживаемые группы) параметров TLS. Введение данных групп позволяет узлам (англ. peer) установить общие параметры алгоритма Диффи-Хеллмана для конечного поля (англ. common finite field DH parameters), что позволяет устранить недостатки традиционного обмена ключами с использованием алгоритма Диффи-Хеллмана на основе конечного поля.

J. Salowey, S. Turner «IANA Registry Updates for TLS and DTLS», RFC 8447, August 2018 – Документ описывает изменения в регистрах IANA для протоколов TLS[4] и DTLS, начиная добавлением примечаний, заканчивая изменением политики регистрации.

Сам текст стандарта протокола может содержать ошибки, которые указываются в специальном разделе «Errata». Все ошибки разделены на два типа – подтвержденные (англ. verified) и неподтвержденные (англ. reported). Текст стандарта приводится с учетом подтвержденных ошибок. Указанные ошибки в тексте перевода учитываться не будут, но места в тексте, имеющие указание на ошибку, будут отмечаться соответствующим комментарием.

Первая часть перевода содержит вступительную часть, описание псевдоязыка и хэш-функции HMAC. Вторая часть перевода будет содержать описание протокола записи (TLS Record Protocol), третья – протокола процесса рукопожатия (TLS Handshaking Protocol), четвертая – заключительные положения и приложения.

Ссылки на нормативные источники и литературу будут приведены как в примечаниях, так и в соответствии с текстом спецификации – в разделах «Литература» и «Нормативные источники» с расшифровкой условного обозначения работ. Условные обозначения для каждой работы даются в квадратных скобках и соответствуют оригинальному тексту документа. Все источники будут даваться так, как они приведены в тексте стандарта без перевода названия на русский язык.

Все примечания, сделанные переводчиком сопровождаются пометкой «(Прим. перев.)».

• 6. Протокол записи TLS
• 6.1. Состояния соединения
• 6.2. Уровень записей
• 6.2.1. Фрагментация
• 6.2.2. Сжатие и распаковка записей
• 6.2.3. Защита записей
• 6.2.3.1. Нулевой шифр и стандартный потоковый шифр
• 6.2.3.2. Блочный шифр в режиме сцепления блоков (CBC-шифр)
• 6.2.3.3. Шифры AEAD (с дополнительно прикрепляемыми данными)
• 6.3. Вычисление ключа

• 7. Протоколы процесса рукопожатия TLS
• 7.1. Протокол изменения параметров шифрования (Change Cipher Spec)
• 7.2. Протокол оповещений
• 7.2.1. Оповещения о закрытии соединения
• 7.2.2. Сообщения об ошибках
• 7.3. Обзор протокола рукопожатия
• 7.4. Протокол рукопожатия
• 7.4.1. Hello-сообщения
• 7.4.1.1. Hello-запрос (Hello Request)
• 7.4.1.2. Клиентское hello-сообщение
• 7.4.1.3. Серверное hello-сообщение
• 7.4.1.4. Расширения hello-сообщений
• 7.4.1.4.1. Расширение «алгоритмы подписи» (signature_algorithms)

• 7.4.2. Серверный сертификат
• 7.4.3. Серверное сообщение обмена ключами (ServerKeyExchange)
• 7.4.4. Запрос сертификата
• 7.4.5. Сообщение ServerHelloDone (завершение серверного этапа отправки hello-сообщений)
• 7.4.6. Клиентский сертификат
• 7.4.7. Клиентское сообщение обмена ключами (ClientKeyExchange)
• 7.4.7.1. Сообщение с предварительным секретом, зашифрованное алгоритмом RSA
• 7.4.7.2. Открытое число клиента в алгоритме Диффи-Хеллмана
• 7.4.8. Сообщение о проверке сертификата (CertificateVerify)
• 7.4.9. Сообщение Finished
• 8. Криптографические вычисления
• 8.1. Вычисление основного секрета
• 8.1.1. Алгоритм RSA
• 8.1.2. Алгоритм Диффи-Хеллмана
• 9. Обязательные криптонаборы
• 10. Протокол данных приложения
• 11. Вопросы безопасности
• 12. Регистры IANA

Общая часть

Данный документ описывает версию 1.2 протокола безопасности транспортного уровня TLS (англ. Transport Layer Security). Протокол TLS обеспечивает безопасность соединения в Интернете. Протокол позволяет клиент-серверным приложениям устанавливать между собой соединение, предотвращающее перехват (англ. eavesdropping), злонамеренное использование (англ. tampering) и фальсификацию (англ. forgery) сообщения.

1. Введение

Главная задача, реализуемая протоколом TLS – обеспечение конфиденциальности (англ. privacy) и целостности данных (англ. data integrity) при соединении между двумя приложениями. Протокол состоит из двух слоев: TLS Record Protocol (протокол записи) и TLS Handshake Protocol (протокол рукопожатия) [5]. На нижнем уровне, находящемся поверх какого-либо надежного транспортного протокола (напр. TCP [TCP][6]), находится TLS Record Protocol. TLS Record Protocol обеспечивает безопасность соединения с двумя базовыми свойствами:

Соединение конфиденциально. Для шифрования данных используется симметричное шифрование (напр. AES [AES][7], RC4 [SCH][8] и т. д.). При этом для каждого соединения генерируются уникальные ключи на основе секрета, который согласовывается (англ. to negotiate) при работе другого протокола (напр. TLS Handshake Protocol). TLS Record Protocol может, также, работать и без использования шифрования.

Соединение надежно. При доставке сообщения осуществляется проверка его целостности при помощи кода утентификации сообщения[9] (далее – MAC) с использованием секретного ключа (англ. keyed MAC). Для вычисления MAC используются защищенные хеш-функции, (напр., SHA-1 и т. д.). TLS Record Protocol может функционировать и без вычисления MAC, но чаще всего используется в таком режиме только в том случае, если другой протокол использует TLS Record Protocol в качестве средства передачи (транспорта) для согласования (англ. negotiation) секретных параметров.

TLS Record Protocol используется для инкапсуляции различных протоколов высшего уровня. Один из таких протоколов — TLS Handshake Protocol позволяет серверу и клиенту аутентифицировать друг друга и согласовать алгоритм шифрования и криптографические ключи до того как протокол приложения передаст или получит первые байты данных. TLS Handshake Protocol обеспечивает безопасность соединения с тремя базовыми свойствами:

Аутентифицировать соединяющийся узел (англ. peer) возможно с использованием асимметричного шифрования (тж. шифрования на основе открытого ключа) (англ. public key cryptography) (напр. RSA [RSA][10], DSA [DSS][11] и т. д.). Такая аутентификация может быть и не обязательной, но чаще всего требуется, как минимум, для одного из соединяющихся узлов.

Согласование (англ. negotiation) общего секрета (англ. shared secret) защищено: вырабатываемый секрет[12] невозможно перехватить, и для любого аутентифицированного соединения невозможно получить секрет, даже находясь между двумя соединяющимися узлами.

Согласование секрета надежно: атакующий не может модифицировать соединение во время согласования, не будучи обнаруженным соединяющимися узлами[13].

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

1.1. Требования к терминологии

Ключевые слова и фразы интерпретируются согласно RFC 2119 [REQ]. Ключевое слово «ДОЛЖЕН» «MUST» равноценно словам «ТРЕБУЕТСЯ» «REQUIRED», «БУДЕТ» «SHALL». Ключевая фраза «НЕ ДОЛЖЕН» «MUST NOT», равноценна фразе «НЕ БУДЕТ» «SHALL NOT». Ключевое слово «НУЖНО» «SHOULD» равноценно cлову «РЕКОМЕНДУЕТСЯ» «RECOMMENDED». Ключевая фраза «НЕ НУЖНО» «SHOULD NOT» равноценна фразе «НЕ РЕКОМЕНДУЕТСЯ» «NOT RECOMMENDED». Ключевое слово «МОЖЕТ/ИМЕЕТ ВОЗМОЖНОСТЬ» «MAY» равноценно cлову «НЕ ОБЯЗАТЕЛЬНО» «OPTIONAL». (подробнее см. тж. RFC 2119 [REQ][14]).

1.2. Основные отличия от TLS 1.1

Данный документ является пересмотром протокола TLS 1.1 [TLS1.1][15], в котором улучшена гибкость, особенно в части, касающейся согласования криптографических алгоритмов. Основные изменения:

— Комбинация хеш-функций MD5/SHA-1 используемая для работы псевдослучайной функции (англ. pseudorandom function, PRF) заменена на PRF, указанную в криптонаборах ( cipher-suite-specified ). Все криптонаборы данного документа используют функцию расширенного преобразования данных (англ. data expansion function) P_SHA256 (см. Раздел 5 данного стандарта).

— Комбинация хеш-функций MD5/SHA-1 в документах, подписанных цифровой подписью заменена на вычисление одной хеш-функции (англ. single hash). Подписанные элементы ( digitally-signed ) теперь включают в себя поле, в котором явно указан используемый тип алгоритма хеширования (см. тж. Разд. 4.7 данного стандарта).

— Существенно улучшены возможности для указания клиентом и сервером типов принимаемых ими алгоритмов хеширования и подписи. Это также смягчает некоторые ограничения на типы алгоритмов хеширования и подписи, накладываемых предыдущими версиями TLS.

— Добавлена поддержка аутентифицированного шифрования с дополнительными данными (англ. Authenticated Encryption with Additional Data, AEAD) (см. Разд. 4.7, п. 6.2.3.3).

Существенно улучшены возможности для указания клиентом и сервером типов принимаемых ими алгоритмов хеширования и подписи. Это также смягчает некоторые ограничения на типы алгоритмов хеширования и подписи, накладываемых предыдущими версиями TLS.

-В одном стандарте объединены определение расширений TLS (TLS Extensions definition) (см. п. 7.4.1.4) и AES-криптонаборы (Advanced Encryption Standard – усовершенствованные алгоритмы шифрования TLS), ранее определяемые в других документах ([TLSEXT][16] и [TLSAES][17]).

— Усилена процедура проверки номеров версий параметра EncryptedPreMasterSecret (см. п. 7.4.7.1).

Длина verify_data теперь зависит от криптонабора (по умолчанию – 12). (см. п. 7.4.7.1).

Улучшено описание защиты от атаки Бляйхенбахера/Клима (Bleichenbacher/Klima attack).

Сообщения о событиях (англ. alerts) ДОЛЖНЫ отправляться в большинстве случаев.

— После запроса сертификата ( certificate_request ) клиент ДОЛЖЕН отправлять пустой список сертификатов в том случае, если ему недоступен ни один сертификат.

— Криптонабор TLS_RSA_WITH_AES_128_CBC_SHA стал обязательным для использования при отсутствии иного в стандарте профиля приложения. (см п. 9).

— Добавлены криптонаборы HMAC-SHA256 .

— Удалены криптонаборы IDEA и DES. Они более не используются и будут опубликованы в отдельном документе.

— Поддержка обратно-совместимого с SSLv2 (SSL 2.0) сообщения «hello» теперь МОЖЕТ, а не БУДЕТ осуществляться. Поддержка, вероятно, НЕ БУДЕТ осуществляться в будущем.

— Для того, чтобы однородные case-блоки имели один и тот же код, в псевдоязык добавлено ограниченное «проваливание» (англ. fall-through). (см. тж. п. 4. 6. 1.).

— Добавлены разделы с описанием «подводных камней» при реализации протокола (англ. Implementation Pitfalls).

— Проведена редакторская работа для более ясного изложения материала.

2. Цели создания протокола

Цели разработки протокола TLS, в порядке значимости, следующие:

1. Криптографическая защита: TLS рекомендуется использовать для установления защищенного соединения между двумя сторонами (англ. parties).
2. Универсальное взаимодействие (Interoperability): независимые разработчики должны иметь возможность разрабатывать приложения, использующие TLS, которые могут обмениваться криптографическими параметрами без знания кода другого приложения.
3. Расширяемость: TLS стремится создать такую конструкцию, в которую при необходимости могут быть внедрены новые методы работы с открытыми ключами и канальным шифрованием (англ. bulk encryption). Для этого потребуется выполнить две подзадачи: исключить необходимость создания нового протокола (с рисками возникновения новых уязвимостей), а также исключение необходимости разработки новой библиотеки для целей безопасности.
4. Относительная эффективность: Криптографические операции задействуют все больше вычислительной мощности, в частности – операции с открытым ключом. В связи с эти TLS включил в себя опциональную схему кеширования сессий, что позволит уменьшить количество соединений, устанавливаемых с изначальной точки (англ. from scratch). Кроме того, были приложены усилия для уменьшения сетевой активности.

3. Цели создания документа

Данный документ и сам протокол TLS основаны на спецификации протокола SSL 3.0, опубликованной фирмой Netscape. Различия между данным протоколом и протоколом SSL 3.0 – не критические, но они достаточно значимые для того, чтобы различные версии TLS и протокол SSL 3.0 могли не взаимодействовать между собой (хотя каждый протокол и содержит механизмы, которые позволяют ему возвращаться к предыдущим версиям). Данный документ предназначен, прежде всего, для разработчиков, внедряющих протокол в свои приложения, и для специалистов, занимающихся его криптографическим анализом. Спецификация была написана с учетом этого и предназначена для того, чтобы удовлетворить интересы указанных двух групп. По этой причине многие структуры данных, зависящие от алгоритмов, включены в текст спецификации (представлены в Приложениях), позволяя получить к ним более легкий доступ.

Данный документ не предназначен для раскрытия каких-либо деталей определения служб (англ. service definition) или определения интерфейсов (англ. interface definition), хотя он и содержит места с описанием отдельных политик, поскольку в этом случае они требуются для поддержания устойчивой безопасности.

4. Псевдоязык

Данный документ содержит особый формат внешнего представления (англ. external representation)[18] данных. В нем используется весьма обобщенный и нестрого определенный синтаксис. Синтаксис псевдоязыка в своей структуре имеет несколько источников. Хотя в своем синтаксисе он и похож на язык «C», и на XDR [XDR][19] – в своем синтаксисе и содержимом, было бы слишком опрометчиво проводить слишком много параллелей между ними. Цель создания этого псевдоязыка – использование в документации протокола TLS; у него нет какого-либо применения, выходящего за пределы этой цели.

4.1. Базовый размер блока

Представление всех элементов данных (англ. data item) явно определено. Базовый размер блока данных – один байт (т. е. 8 бит). Элементы данных, содержащие больше одного байта (далее – мультибайтовый элемент)– являются конкатенацией байтов, слева направо, сверху вниз. Мультибайтовый элемент (числовой в следующем примере) образуется из потока байтов (в нотации языка C) следующим образом:

Такой алгоритм размещения байтов (англ. byte ordering) в мультибайтовых значениях является стандартным сетевым порядком байтов (англ. network byte order), который, также, называется форматом от старшего к младшему (англ. big-endian format, BE format).

4.2. Разное

Комментарии начинаются с символов « /* » и заканчиваются символами « */ ».

Необязательные компоненты обозначаются заключением их в двойные скобки « [[ ]] ».

Однобайтовые элементы (англ. single-byte entities), содержащие неинтерпретируемые данные, имеют непрозрачный тип данных (англ. type opaque).

4.3. Векторы

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

Здесь T’ занимает n байт в потоке данных, где n – кратно размеру T . Размер длины вектора не включается в кодированный поток.

В следующем примере Datum определен как три последовательных байта, не интерпретируемых протоколом, а Data – как три последовательных вектора Datum , которые в общей сложности, имеют длину 9 байтов:

opaque [21] Datum[3]; /* три неинтерпретируемых байта */
Datum Data[9]; /* 3 последовательных 3-байтовых вектора */

Векторы переменной длины определяются заданием поддиапазона действительных длин (англ. subrange of legal lengths) с использованием нотации ( ). Когда поддиапазон задан, длина вектора предшествует основному содержимому вектора в байтовом потоке данных. Длина вектора задается таким типом целого числа, который может потребоваться для хранения заданного значения максимальной длины вектора (значение ceiling ( потолок )), даже если текущее значение длины можно сохранить, задав для его хранения меньшее количество байтов. Вектор переменной длины, имеющий в поле размера значение 0, рассматривается как пустой вектор.

В следующем примере mandatory – это вектор, который должен содержать от 300 до 400 байт данных непрозрачного типа. Он ни в коем случае не может быть пустым. Поле длины указанного вектора должно иметь тип uint16, занимая, таким образом 2 байта в памяти. Такой размер поля является достаточным для представления числа 400 (см. раздел 4. 4.).

С другой стороны, вектор longer может иметь размер до 800 байт, что может составить 400 элементов (блоков) типа uint16 , также он может быть пустым. Его код должен включать двухбайтовое поле со значением длины (также, типа uint16 ), которое предшествует самому вектору. Длина закодированного вектора в данном случае должна быть четным числом (например, длина вектора, имеющего тип данных uint16 , равная 17 байт, будет некорректной).

opaque mandatory;/* поле длины занимает 2 байта, не может быть пустым */
uint16 longer; /* от 0 до 400 беззнаковых целых чисел размером 16 бит (2 байта)*/

4.4. Числа

Базовый числовой тип данных – беззнаковый байт ( uint8 ). Все типы данных с большим размером – образуются из последовательностей байтов фиксированной длины, конкатенирующихся по правилам, указанным в разделе 4.1, и также являются беззнаковыми. Предопределены следующие числовые типы данных:

uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];

Все значения, указанные здесь или где-либо еще в спецификации – приведены в сетевом формате (от большего к меньшему) (англ. big-endian order). Число типа uint32 , представленное 4 байтами с 16-ричными значениями (hex bytes) 01 02 03 04 эквивалентно десятичному числу 16909060.

Обратите внимание, что в некоторых случаях (например при расчете параметров DH (параметров алгоритма Диффи-Хеллмана) необходимо представлять целые числа как непрозрачные векторы. В таких случаях они представляются как беззнаковые целые (т. е., отсутствует требование о наличии в старших разрядах нулевых октетов, даже если самый старший бит числа равняется 1).

4.5. Перечисления (перечисленный тип)

В алгоритме доступен также иногда встречающийся тип данных enum (перечисленный тип или перечисление) (англ. enumerated). Поле, имеющее значение типа enum , может содержать только значения, указанные в определении перечисления. Каждое такое определение задает отличный от других определений тип. Сравниваться или получать значения могут только элементы (тж. указатели), принадлежащие одному определению (типу). Каждому элементу перечисления должно быть присвоено значение так, как это указано в примере ниже. Поскольку порядок расстановки элементов в определении перечисления не установлен, им может быть присвоено любое уникальное значение в любом порядке:

Перечисления занимают в битовом потоке столько места, сколько заняло бы максимальное значение указателя в его определении. Нижеприведенное определение задает размер поля типа Color , равный одному байту:

Чтобы избежать определения излишних элементов, есть дополнительная возможность определить значение без присоединенного к нему указателя (англ. associated tag).

В следующем примере поле типа Taste займет в потоке данных два байта, но при этом сможет принимать значения только 1, 2 или 4.

Имена элементов перечисления ограничены именами, перечисленными в его определении. В первом примере полная ссылка на второй элемент перечисления будет выглядеть как Color.blue . Такой тип ссылки не является обязательным, если цель, которой присваивается имя, правильно определена:

Color color = Color.blue; /* может использоваться, избыточно */
Color color = blue; /* корректно, неявное указание */

Числовая информация может не указываться для перечислений, которые не будут преобразованы во внешнее представление:

4.6. Структурированные типы (структуры)

Для удобства, можно создать типы структур из простейших типов. Каждая декларация (определение) задает новый уникальный тип. Синтаксис такой декларации в большой степени похож на синтаксис языка C:

struct < T1 f1; T2 f2; . Tn fn; >[[T]]; 

Ссылки на поля внутри структуры могут быть даны с использованием имени его типа, при этом синтаксис будет очень похож на синтаксис ссылок на элементы перечислений. Например, T.f2 дает ссылку на второе поле предыдущей декларации. Определения (декларации) структурных типов данных могут быть встроенными (англ. embedded).

4.6.1. Варианты

Продекларированные структуры могут включать в себя варианты, выбор которых основывается на некоторых особенностях окружения. Механизм выбора вариантов (англ. selector) задается перечислением, которое определяет возможные варианты, определенные структурой. Для каждого элемента перечисления, задающего механизм выбора, должен иметься свой вариант, задаваемый оператором case (англ. case arm), внутри определения, задающего структурный тип. Варианты имеют механизм ограниченного проваливания[22]: если два варианта идут непосредственно друг за другом и не имеют полей между собой, то в этом случае оба они будут содержать одни и те же поля. Так, в нижеприведенном примере два варианта « orange » и « banana » будут содержать поле со значением V2 . Обратите внимание, что данный синтаксис является новшеством протокола TLS 1.2.

Для указания на структуру выбора вариантов к ней может быть прикреплена метка (англ. label). В псевдоязыке не представлен механизм, при помощи которого происходит выбор варианта при запуске приложения.

 struct < T1 f1; T2 f2; . Tn fn; select (E) < case e1: Te1; case e2: Te2; case e3: case e4: Te3; . case en: Ten; >[[fv]]; > [[Tv]];

struct <
uint16 number;
opaque string; /* переменная длина */
> V1;

struct uint32 number;
opaque string[10]; /* фиксированная длина */
> V2;

struct select (VariantTag) < /* неявное значение механизма выбора*/
case apple:
V1; /* VariantBody, указатель = apple */
case orange:
case banana:
V2;/* VariantBody, указатель = orange или banana */
> variant_body; /* необязательная метка структуры вариантов*/
> VariantRecord;

4.7. Криптографические атрибуты

Алгоритмом определено пять криптографических операций – цифровое подписание (англ. digital signing), потоковое шифрование (англ. stream cipher encryption), блочное шифрование (англ. block cipher encryption), аутентифицированное шифрование с дополнительными данными (англ. authenticated encryption with additional data (AEAD)), шифрование с открытым ключом (англ. public key encryption). Указанные операции имеют следующие ключевые обозначения (англ. key word designation): digitally-signed , stream-ciphered , block-ciphered , aead-ciphered , и public-key-encrypted , соответственно. Криптографическая обработка поля определяется путем прикрепления к нему спереди соответствующего ключевого обозначения, идущего перед описанием типа этого поля. На криптографические ключи влияет рабочее состояние сессии (см. Разд. 6. 1).

Элемент digitally-signed кодируется как структурированный тип (struct) DigitallySigned :

struct <
SignatureAndHashAlgorithm algorithm;
opaque signature;
> DigitallySigned;

Поле algorithm описывает используемый алгоритм (см. п. 7.4.1.4.1. для подробной информации об этом поле). Обратите внимание, что введение поля algorithm является изменением по сравнению с предыдущими версиями. Поле signature – цифровая подпись, использующая указанные алгоритмы на содержимом элемента. Само содержимое этого поля находится не в сети, но вычисляется простым образом. Длина подписи определяется алгоритмом подписи и ключом.

При использовании для подписи алгоритма RSA, непрозрачный вектор содержит подпись, сгенерированную схемой RSASSA-PKCS1-v1_5 , описанной в [PKCS1][23]. В обсуждении, поднятом в [PKCS1], было условлено, что тип данных DigestInfo [24][25] должен быть закодирован с использованием отличительных правил кодирования (англ. Distinguished Encoding Rules (DER))) [X680][26] [X690][27]. Для непараметрических алгоритмов хеширования (включая SHA-1), поле DigestInfo.AlgorithmIdentifier.parameters должно содержать значение NULL , но реализуемые приложения должны работать как со значением этого поля NULL , так и, вообще, без указания параметров. Обратите внимание, что более ранние версии TLS использовали другую схему подписания на основе алгоритма RSA, которая не включала в себя использование DigestInfo .

При использовании для подписи алгоритма DSA, 20 байт хеша, полученного при помощи алгоритма SHA-1, пропускаются непосредственно через алгоритм цифрового подписания (англ. Digital Signing Algorithm (DSA)) без дополнительного хеширования. При этом рассчитывается два значения – r и s. Подпись, полученная при помощи DSA, является непрозрачным вектором, как и в случае использования RSA, содержимое которого рассчитывается при помощи DER-кодирования последовательности Dss-Sig-Value . При этом, Dss-Sig-Value выражается как:

Dss-Sig-Value ::= [28] SEQUENCE [29] <
r INTEGER,
s INTEGER,
>

Обратите внимание: в текущей терминологии аббревиатура «DSA» означает «Digital Signature Algorithm» (то есть, относится к алгоритму), в то же время аббревиатура «DSS» относится к стандарту NIST[30]. В оригинальных спецификациях TLS и SSL использовалась только аббревиатура «DSS». Данный документ для обозначения алгоритма использует аббревиатуру «DSA», а для обозначения стандарта – «DSS». В то же время использование в определениях кода аббревиатуры «DSS» сделано в целях исторической преемственности.

При потоковом шифровании криптографически защищенный генератор псевдослучайных чисел с ключом (англ. secure keyed pseudorandom number generator) генерирует последовательность, равную по размеру незашифрованному сообщению (англ. plaintext), после получают зашифрованное сообщение, применяя операцию сложения по модулю 2 (исключающего «ИЛИ») исходного сообщения и сгенерированной псевдослучайной последовательности.

При блочном шифровании каждый блок незашифрованного сообщения зашифровывается в блок шифротекста. Блочное шифрование происходит в режиме построения цепи шифроблоков (англ. Cipher Block Chaining, CBC). Размер зашифрованных, таким образом, элементов, будет кратен длине шифроблока.

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

При шифровании с открытым ключом алгоритм открытого ключа используется для шифрования данных таким образом, чтобы расшифровка могла произойти только при помощи соответствующего закрытого ключа. Элемент public-key-encrypted (зашифрованный открытым ключом) является непрозрачным вектором переменной длины , определяемой алгоритмом шифрования и ключом.

RSA-шифрование выполняется на основе схемы RSAES-PKCS1-v1_5 , указанной в [PKCS1].

В следующем примере содержимое внутренней структуры ( field3 и field4 ) используется как входные данные для алгоритма подписи/хеширования, таким образом, вся структура целиком шифруется в потоковом режиме. Длина структуры в байтах будет равна два байта для полей field1 и field2 плюс два байта для алгоритма подписи и хеширования, плюс два байта для файла подписи, плюс длина выходных данных алгоритма подписи. Размер файла подписи известен, так как алгоритм и ключ, используемый для подписи, известны заранее до шифрования или дешифрования этой структуры.

stream-ciphered struct uint8 field1;
uint8 field2;
digitally-signed opaque uint8 field3;
uint8 field4;
>;
> UserType;

4.8. Константы

Для целей спецификации типизованные константы могут быть определены путем объявления желаемого типа и присвоения ему значений.

Неопределенным типам (непрозрачным (англ. opaque), векторам переменной длины, структурам, содержащим непрозрачный тип) не могут присваиваться значения. Ни одно из полей мульти-элементной структуры или вектора не может быть пропущено.

struct uint8 f1;
uint8 f2;
> Example1;

Таким образом, структура типа Example1 будет содержать два поля f1 и f2 со значениями 1 и 4, соответственно.

5. HMAC и псевдослучайная функция

Для защиты целостности сообщений слой записи TLS (англ. TLS record layer) использует MAC с ключом (англ. keyed MAC). Шифронаборы (тж. криптонаборы) (англ. cipher suites), определенные в этом документе, используют конструкцию, известную как HMAC, в которой происходит хеширование MAC-аутентификатора, описанную в [HMAC][31]. При необходимости другие криптонаборы могут определять свои собственные MAC-конструкции.

В добавок к этому, этой конструкции требуется расширенное преобразование (англ. expansion) секретов в блоки данных для целей генерации либо валидации ключа. Данная псевдослучайная функция (англ. Pseudo Random Function (PRF)) в качестве входных данных берет секрет, свое начальное значение (тж. затравка) (англ. seed), метку идентификации (англ. identifying label, label) и выдает данные произвольной длины.

В данном разделе мы определяем только одну PRF, которая основана на алгоритме HMAC. Данная функция, работающая в связке с хеш-функцией SHA-256, используется для всех криптонаборов, определенных в этом документе, а также в других документах, касающихся протокола TLS 1.2, опубликованных ранее этого документа. Новые криптонаборы должны явно определять PRF и, в общем случае, должны использовать для протокола TLS PRF с хеш-функцией SHA-256, либо с более сильным стандартом хеширования.

Для начала определим функцию расширенного преобразования данных (англ. data expansion function) P_hash(secret, data) , которая использует одну хеш-функцию для преобразования секрета и начального значения в выходные данные произвольного размера:

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + .

где «+» означает конкатенацию.

A() определяется как:

A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))

Функция P_hash может иметь столько итераций, сколько это необходимо для выдачи требуемого количества данных. Например, если P_SHA256 используется для создания 80 байт данных, то необходимо будет произвести три итерации функции (до A(3) включительно), создав 96 байт выходных данных; последние 16 байтов финальной итерации будут отброшены, оставив 80 байт выходных данных.

PRF для целей протокола TLS создается путем применения функции P_hash с секретом в качестве ее аргумента:

PRF(secret, label, seed) = P_(secret, label + seed)

Метка (англ. label) является ASCII-строкой. Ее следует включать в функцию в точной форме, в которой она была взята, без байта длины, а также не перенося нулевой символ (англ. null character). Например, метка «slithy toves», до начала обработки функцией хеширования будет выглядеть как:

73 [32] 6C 69 74 68 79 20 74 6F 76 65 73

[1] Клиентские и серверные сообщения «hello» рассмотрены в п. 7.4.1 данного стандарта (Прим. перев.).

[2] Хотя в некоторых русскоязычных источниках слово «deprecating» дается в переводе «устаревание», автору перевода наиболее подходящим видится термин «прекращение использования», поскольку для термина «устаревший» в английском языке используется слово «obsolete» (Прим. перев.).

[3] Клиентское сообщение об обмене ключами (Client Key Exchange Message) содержит начальный ключ (англ. premaster key) после чего псевдослучайная функция вычисляет основной ключ (англ. master key) (подробнее см. разделы 7.4.7 и 8.1 спецификации протокола TLS 1.2) (Прим. перев.).

[4] Регистры IANA для TLS разделены на две части: Transport Layer Security (TLS) Parameters (Параметры TLS) и Transport Layer Security (TLS) Extensions (Расширения TLS) (Прим. перев.).

[5] Протокол рукопожатия также можно назвать протоколом согласования параметров. Но поскольку для термина «согласование параметров» в английском языке имеется слово «negotiation», был оставлен используемый в официальном документе для обозначения данного уровня протокола TLS сленговый термин «рукопожатие» (англ. handshake) (Прим. перев.).

[6] Postel, J., «Transmission Control Protocol«, STD 7, RFC 793, September 1981.

[7] National Institute of Standards and Technology,»Specification for the Advanced Encryption Standard (AES)» FIPS 197. November 26, 2001.

[8] B. Schneier. «Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd ed.», Published by John Wiley & Sons, Inc. 1996.

[9] В русскоязычной источниках также используется термин «имитовставка».(Прим. перев.).

[10] R. Rivest, A. Shamir, and L. M. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems«, Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126.

[11] NIST FIPS PUB 186-2, «Digital Signature Standard«, National Institute of Standards and Technology, U.S. Department of Commerce, 2000. — На август 2021 года указанный стандарт является недействующим. Действующий стандарт — NIST FIPS 186-4, «Digital Signature Standard», National Institute of Standards and Technology, U.S. Department of Commerce, 2013 (Прим. перев.).

[12] Также можно употребить термин «секретный ключ».(Прим. перев.).

[13] Как было сказано в предисловии, в сентябре 2015 года вышел RFC 7627, который направлен на устранение уязвимости от атаки «man-in-the-middle», в которой злоумышленник устанавливает две сессии с клиентом и сервером, используя один и тот же секрет (секретный ключ). (Прим. перев.).

[14] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels«, BCP 14, RFC 2119, March 1997.

[15] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.1«, RFC 4346, April 2006.

[16] Eastlake, D., 3rd, «Transport Layer Security (TLS) Extensions: Extension Definitions«, Work in Progress, February 2008. – На август 2021 года актуальной версией является: Eastlake, D., 3rd, «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC 6066, January 2011 (Прим. перев.). – Поддерживаемые IANA расширения TLS также приведены в разделе регистров Transport Layer Security (TLS) Extensions. (Прим. перев.).

[17] Chown, P., «Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)«, RFC 3268, June 2002.

[18] Внешнее представление (англ. external representation) является англоязычным термином для структурированного представления данных и информации, включающего как формальные структуры, так и и наглядный материал (графики, схемы, иллюстрации). Данный термин в англоязычной литературе противопоставляется внутреннему представлению данных (internal representation) или, также, промежуточному представлению (intermediate representation), обозначающему структуры данных или код, используемые компилятором или виртуальной машиной для представления исходного кода. (Прим. перев.).

[19] Eisler, M., Ed., «XDR: External Data Representation Standard«, STD 67, RFC 4506, May 2006.

[21] Opaque – непрозрачный тип данных. См. тж. раздел 4. 2 (Прим. перев.).

[22] Проваливанием (англ. fall-through) в языках С/C++ называется ситуация, когда в блоке case оператора передачи управления switch отсутствует служебное слово brake . До стандарта C++17 компилятор в этом случае выдал бы сообщение об ошибке проваливания. (Прим. перев.).

[23] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1«, RFC 3447, February 2003.

[24] О синтаксисе типа DigestInfo см. раздел A.2.4 RFC 3447 [PKCS1] (Прим. перев.).

[25] Результат преобразования данных хеш-функцией в английском языке может обозначаться термином «digest», что в русскоязычной литературе может переводиться как «сводка сообщения». (Прим. перев.).

[26] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation.

Российский аналог — ГОСТ Р ИСО/МЭК 8824-1-2001. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации. (Прим. перев.).

[27] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology — ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

Российский аналог — ГОСТ Р ИСО/МЭК 8825-1-2003 Информационная технология. Правила кодирования ACH.1. Часть 1. Спецификация базовых (BER), канонических (СER) и отличительных (DER) правил кодирования.

[28] ::= — символ определения в форме нотации Бэкуса-Наура. (Прим. перев.).

[29] Sequence (англ.) – последовательность. В информатике – порядок действий, задаваемых алгоритмом. Таким образом, Dss-Sig-Value является последовательным вычислением значений r и s .

[30] NIST — The National Institute of Standards and Technology, Национальный институт стандартов и технологии (США). (Прим. перев.).

[31] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication«, RFC 2104, February 1997.

[32] 73 – ASCII-код в 16-ричном формате для символа «s» и т. д. (Прим. перев.).

[33] Операция побитового ИЛИ (Прим. перев.).

RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2

В этом документе описан предлагаемый стандарт протокола для сообщества Internet; документ служит приглашением к дискуссии в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Данный документ может распространяться свободно.

Этот документ содержит спецификацию версии 1.2 протокола TLS 1 , который обеспечивает защиту коммуникаций через Internet. Протокол обеспечивает приложениям «клиент-сервер» способ обмена данными, предотвращающий перехват, фальсификацию и подмену сообщений.

1. Введение

Основной задачей протокола TLS является обеспечение конфиденциальности и целостности данных, передаваемых между двумя коммуникационными приложениями. Протокол включает два уровня: TLS Record Protocol и TLS Handshake Protocol. Нижний уровень, расположенный поверх того или иного транспортного протокола с гарантированной доставкой (например, TCP [TCP]), называется протоколом TLS Record. Этот протокол обеспечивает безопасность соединений и обладает двумя основными свойствами.

• Конфиденциальность соединения. Для шифрования данных используется симметричная схема (например, AES [AES], RC4 [SCH] и т. п.). Уникальные ключи для симметричного шифрования генерируются для каждого соединения на основе секретного ключа, согласованного с помощью другого протокола (например, TLS Handshake). Протокол Record может использоваться и без шифрования.
• Надежность соединения. Транспортировка сообщений включает проверку целостности с использованием кодов MAC на основе ключей. Для расчета MAC используются защитные хэш-функции (например, SHA-1 и т. п.). Протокол Record может работать без MAC, но такой режим обычно применяется только при использовании протокола Record в качестве транспорта для согласования параметров безопасности.

Протокол TLS Record служит для инкапсуляции различных протоколов вышележащего уровня. Одним из таких протоколов является TLS Handshake Protocol, который позволяет серверу и клиенту выполнить аутентификацию другой стороны и согласовать алгоритм шифрования и ключи до того, как протокол прикладного уровня начнет передачу или прием первого байта данных. Протокол TLS Handshake обеспечивает безопасные соединения, которые обладают тремя основными свойствами, перечисленными ниже.

• Идентификация и аутентификация партнера может проводиться с использованием асимметричных (открытых) ключей (например, RSA [RSA], DSA [DSS] и т. п). Такая проверка подлинности не является обязательной, но в общем случае требуется по крайней мере на одной стороне.
• Процесс согласования общего секрета защищен – согласованный ключ недоступен для прослушивания и получить ключ для любого аутентифицированного соединения невозможно, даже если атакующий может перехватывать проходящие через соединение пакеты.
• Процесс согласования надежен – атакующий не может повлиять на этот процесс, не будучи обнаруженным участниками соединения.

Преимуществом TLS является независимость от протоколов прикладных уровней. Для протоколов вышележащих уровней TLS обеспечивает полную прозрачность. Стандарт TLS не задает способ использования TLS другими протоколами – решение о процедуре согласования TLS и интерпретации обмена сертификатами аутентификации принимают разработчики протоколов, работающих на основе TLS.

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [REQ].

1.2. Основные отличия от TLS 1.1

Этот документ является пересмотром спецификации TLS 1.1 [TLS1.1], обеспечивающим повышение уровня гибкости, прежде всего при согласовании криптографических алгоритмов. Основные отличия нового протокола приведены ниже:

• комбинация MD5/SHA-1 в псевдослучайной функции (PRF 1 ) заменена PRF, определяемыми выбранным шифронабором (все определенные в этом документе шифронаборы используют функцию P_SHA256);
• комбинация MD5/SHA-1 в элементах с цифровой подписью заменена одним хэш-значением и подписанные элементы включают поле, явно указывающее используемый алгоритм хэширования;
• существенно упрощена для клиентов и серверов возможность задания алгоритмов подписи и хэширования, которые они будут воспринимать, что также смягчило требования к алгоритмам подписи и хэширования, принятые в прежних версиях TLS;
• добавлена поддержка аутентифицированного шифрования с дополнительными режимами;
• добавлены определения расширений TLS и шифронаборов AES, заимствованные из [TLSEXT] и [TLSAES];
• усилена проверка номера версии EncryptedPreMasterSecret;
• увеличено число требований;
• размер v erify_data стал зависеть от шифронабора (по умолчанию сохраняется значение 12);
• уточнено описание опасности атак Bleichenbacher/Klima;
• во многих случаях должны передаваться сигналы;
• если после certificate_request нет доступных сертификатов, клиент должен передавать пустой список сертификатов;
• шифронабор TLS_RSA_WITH_AES_128_CBC_SHA стал обязательным для реализации;
• добавлены шифронаборы HMAC-SHA256;
• удалены шифронаборы IDEA и DES (они сочтены устаревшими и будут описаны в отдельном документе);
• поддержка совместимых с SSLv2 сообщений hello может быть реализована (ранее ее следовало реализовать), передавать такие сообщения не следует (в будущем может быть принято решение о том, что поддерживать такие сообщения не следует);
• в язык представления добавлены «проходные» варианты (limited “fall-through”), позволяющие использовать общий код для множества вариантов;
• д обавлен о Приложение D.4. «Подводные камни» реализации;
• обычные разъяснения и редакторские правки.

2. Назначение протокола

Основные цели протокола TLS (в порядке снижения важности) перечислены ниже.

1. Криптографическая защита – протокол TLS следует использовать для организации защищенных соединений между парами точек.
2. Интероперабельность – независимые разработчики программ должны иметь возможность создания использующих TLS приложений, которые смогут обмениваться параметрами шифрования с другими подобными приложениями, не зная ничего об их программном коде.
3. Расширяемость – протокол TLS предназначен стать базой, к которой могут добавляться новые методы шифрования и работы с открытыми ключами. Это позволит избавиться от необходимости разработки новых протоколов (риск добавления новых уязвимостей) и создания новых библиотек функций обеспечения безопасности.
4. Эффективность — криптография требует больших вычислительных ресурсов, в частности, для операций с открытыми ключами. По этой причине протокол TLS включает дополнительную схему кэширования сессий, снижающую число организуемых с нуля соединений. В дополнение к этому приняты меры по снижению уровня служебного сетевого трафика.

3. Назначение документа

Протокол TLS и описанная в данном документе спецификация этого протокола основаны на спецификации протокола SSL 3.0, опубликованной компанией Netscape. Различия между SSL 3.0 и TLS не критичны, но достаточно существенны – версии TLS и SSL 3.0 не могут взаимодействовать между собой (хотя каждый включает механизм совместимости с предыдущими версиями). Данный документ адресован прежде всего читателям, планирующим реализовать протокол или выполняющим его криптографический анализ. Спецификация протокола написана с учетом требований этих двух групп. По этой причине многие зависящие от алгоритма структуры данных и правила включены в текст документа (а не в приложения), чтобы упростить доступ к информации об этих структурах и правилах.

Документ не содержит детальных определений служб или интерфейсов, хотя в нем рассматриваются отдельные сферы политики, требуемые для обеспечения высокого уровня безопасности.

4. Язык представления

Этот документ имеет дело с форматированием данных для внешнего представления. В документе используется очень простой синтаксис, похожий на синтаксис языка программирования C и синтаксис XDR [XDR]. Используемый в документе язык представления предназначен только для TLS и не имеет применения за пределами этого стандарта.

4.1. Размер базового блока

Представление всех элементов данных описано в явной форме. Базовый блок данных имеет размер 1 байт (8 битов). Многобайтовые элементы данных объединяются (конкатенация) слева направо и сверху вниз. Из байтового потока многобайтовый элемент (например, число) формируется следующим образом (используется нотация языка C):

значение = (байт[0] 
Для многобайтовых значений используется сетевой порядок следования байтов 2 .
4.2. Различные элементы
Текст комментария начинается с символов /* и заканчивается символами */.
Необязательные компоненты заключены в двойные квадратные скобки [[ ]].
Однобайтовые элементы, содержащие неинтерпретируемые данные, имеют тип opaque 3 .
4.3. Векторы
Вектор (одномерный массив) представляет собой поток однородных элементов данных. Размер вектора может быть указан в документации или согласован во время работы. В любом случае размер задается в байтах, а не числом элементов вектора. Синтаксис задания нового типа T’, который относится к векторам фиксированного размера типа T имеет вид
T T'[n];
Вектор T’ занимает n байтов в потоке данных, где значение n кратно размеру T. Размер вектора не включается в кодированный поток данных.
В приведенном ниже примере Datum определяется как три последовательных байта, которые протокол не интерпретирует, а Data – три последовательных элемента Datum, занимающих в общей сложности 9 байтов.
opaque Datum[3]; /* три неинтерпретируемых байта */ Datum Data[9]; /* 3 последовательных 3-байтовых вектора */
Векторы переменной длины определяются с указанием допустимого диапазона размеров (включая крайние значения) в форме . При кодировании в поток данных перед самим вектором помещается его реальный размер. Размер задается в форме числа, занимающего столько байтов, сколько требуется для хранения максимального (ceiling) размера вектора. Вектор переменной длины, имеющий нулевой размер, указывается как пустой вектор.
В приведенном ниже примере mandatory представляет собой вектор типа opaque размером от 300 до 400 байтов. Такой вектор никогда не может быть пустым. Поле размера занимает два байта (uint16), что достаточно для записи максимальной длины вектора 400 (см. параграф 4.4). Вектор longer может представлять до 800 байтов данных или до 400 элементов uint16 и может быть пустым. Кодирование вектора включает двухбайтовое поле размера, предшествующее вектору. Размер кодированного вектора должен быть кратным размеру одного элемента (например, значение 17 для вектора uint16 будет некорректным).
opaque mandatory; /* поле размера занимает 2 байта, вектор не может быть пустым */ uint16 longer; /* от 0 до 400 16-битовых беззнаковых целых чисел */
4.4. Числа
Базовым числовым элементов является беззнаковый байт uint8. Все остальные типы чисел формируются из базового типа путем описанной в параграфе 4.1 конкатенации фиксированного числа байтов. Ниже перечислены предопределенные типы чисел.
uint8 uint16[2]; uint8 uint24[3]; uint8 uint32[4]; uint8 uint64[8];
Все числовые значения, используемые в данной спецификации, сохраняются в так называемом сетевом порядке байтов; число uint32, представленное в шестнадцатеричном формате 01 02 03 04, эквивалентно десятичному значению 16909060.
Отметим, что в некоторых случаях (например, параметры DH) требуется использование целых чисел в качестве opaque-векторов. Для этого они представляются целыми числами без знака (т. е., ведущие октеты с нулевыми значениями не требуются, даже в тех случаях, когда старший бит установлен).
4.5. Перечисляемые значения
Используется также дополнительный тип данных – перечисляемые значения или enum. Поле типа enum допускает только значения, заданные при определении этого типа. Каждое определение задает новый перечисляемый тип. В операциях присваивания и сравнения могут использоваться только однотипные перечисляемые значения. Каждому элементу перечисляемого типа должно быть присвоено значение, как показано в приведенном ниже примере. Поскольку элементы перечисляемого типа не упорядочены, каждый элемент должен иметь уникальное значение.
enum < e1(v1), e2(v2), . , en(vn) [[, (n)]] >Te;
Перечисляемые значения занимают в потоке байтов столько места, сколько нужно для записи значения самого большого элемента данного перечисляемого типа. Элементы определенного ниже перечисляемого типа Color будут занимать в потоке по 1 байту.
enum < red(3), blue(5), white(7) >Color;
Можно задать значение без связанного с ним тега для расширения размера типа без создания ненужных элементов. В приведенном ниже определении задается тип Taste, элементы которого занимают в потоке по 2 байта и могут принимать только значения только 1, 2 или 4.
enum < sweet(1), sour(2), bitter(4), (32000) >Taste;
Имена элементов перечисляемого типа доступны только в контексте данного типа. В первом примере полная ссылка на второй элемент типа Color будет иметь вид Color.blue. Полная форма представления не требуется, если целью присваивания является полностью определенный элемент.
Color color = Color.blue; /* полная спецификация – корректно всегда */ Color color = blue; /* корректно при заданном неявно типе */
Для перечисляемых типов, которые никогда не преобразуются для внешнего представления, числовые значения можно опустить
enum < low, medium, high >Amount;
4.6. Структурированные типы
Из примитивов могут создаваться структурированные типы. Каждая спецификация структурированного типа задает новый уникальный тип. Синтаксис описания идентичен синтаксису структур языка C.
struct < T1 f1; T2 f2; . Tn fn; >[[T]];
Поля структуры можно указывать с использованием идентификатора типа, как для перечисляемых значений. Например, T.f2 будет указывать на второе поле определенного выше структурированного типа. Определения структурированных типов могут быть вложенными.
4.6.1. Варианты
Определяемая структура может содержать варианты, выбор между которыми основывается на доступной в среде информации. Селектор вариантов должен относиться к перечисляемому типу, включающему возможные варианты, объявленные в операторе select. Варианты могут быть «проходными» (limited fall-through) – если два варианта непосредственно следуют друг за другом (между ними нет других полей), оба варианта будут содержать одинаковые поля. В приведенном ниже примере варианты orange и banana содержат V2. Отметим, что такой синтаксис введен только в TLS 1.2.
Каждый вариант структуры может иметь метку, используемую для ссылок на этот вариант. Механизм выбора варианта во время работы не описывается языком представления.
struct < T1 f1; T2 f2; . Tn fn; select (E) < case e1: Te1; case e2: Te2; case e3: case e4: Te3; . case en: Ten; >[[fv]]; > [[Tv]];
enum < apple, orange >VariantTag; struct < uint16 number; opaque string; /* переменный размер */ > V1; struct < uint32 number; opaque string[10]; /* фиксированный размер */ >V2; struct < select (VariantTag) < /* значение селектора задано неявно */ case apple: V1; /* VariantBody, tag = apple */ case orange: case banana: V2; /* VariantBody, tag = orange или banana */ >variant_body; /* необязательная метка варианта */ > VariantRecord;
4.7. Криптографические атрибуты
Пять вариантов криптографических операций – цифровая подпись (digital signing), потоковое шифрование (stream cipher encryption), блочное шифрование (block cipher encryption), аутентифицированное шифрование с шифрованием дополнительных данных (AEAD 4 ) и шифрование с открытым ключом (public key encryption) обозначаются ключевыми словами digitally-signed, stream-ciphered, block-ciphered, aead-ciphered и public-key-encrypted, соответственно. Поля с криптографической обработкой указываются с предшествующим типу поля ключевым словом, задающим криптографическую операцию. Ключи шифрования определяются текущим состоянием сессии (см. параграф 6.1).
Элемент с цифровой подписью представляется в форме структуры DigitallySigned
struct < SignatureAndHashAlgorithm algorithm; opaque signature; > DigitallySigned;
Поле algorithm указывает использованный алгоритм (см. определение этого поля в параграфе 7.4.1.4.1). Отметим, что этого поля не было в предыдущих версиях протокола. Поле signature содержит цифровую подпись, полученную с использованием указанного алгоритма применительно к содержимому элемента. Размер поля signature определяется алгоритмом подписи и ключом.
При использовании RSA-подписей opaque-вектор содержит подпись, созданную с использованием схемы RSASSA-PKCS1-v1_5, определенной в [PKCS1]. Как указано в [PKCS1], для DigestInfo должно использоваться представление DER [X680] [X690]. Для алгоритмов хэширования без параметров (к которым относится SHA-1) поле DigestInfo.AlgorithmIdentifier.parameters должно иметь значение NULL, но реализации должны воспринимать как это значение, так и просто отсутствие параметров. Отметим, что в ранних версиях TLS использовалась другая схема для подписей RSA, которая не включала кодирования DigestInfo.
В DSA 20-байтовое хэш-значение SHA-1 создается напрямую с использованием алгоритма DSA 5 без дополнительного хэширования (в результате создаются два значения – r и s). Сигнатура DSA представляет собой opaque-вектор, как сказано выше, содержимое которого является DER-представлением структуры
Dss-Sig-Value ::= SEQUENCE
Примечание. В современной терминологии аббревиатура DSA обозначает Digital Signature Algorithm, а DSS — стандарт NIST. В исходных спецификациях SSL и TLS для обоих случаев применяется обозначение DSS, а в данном документе DSA указывает алгоритм, а DSS — стандарт. Обозначение DSS в определениях сохраняется лишь в целях преемственности.
При потоковом шифровании к тексту применяется операция XOR 6 по отношению к идентичному количеству псевдослучайных чисел, порождаемому криптостойким генератором.
В блочном режиме каждый блок текста преобразуется в шифрованный блок, который создается в режиме CBC 7 . Все элементы шифрованного потока имеют размер, кратный размеру шифрованного блока.
В режиме AEAD для исходного текста используется сразу шифрование и защита целостности. Входные данные могут иметь любой размер, а зашифрованный выход обычно превышает размер входных данных в результате добавления данных контроля целостности .
При шифровании с открытым ключ о м используется алгоритм, шифрующий данные таким образом, что их можно расшифровать только с использованием соответствующего секретного ключа. Шифрованные элементы представляется, как opaque-векторы , размер которых определяется алгоритмом шифрования и ключом.
В режиме RSA шифрование выполняется с использованием схемы RSAES-PKCS1-v1_5, определенной в [PKCS1].
В приведенном ниже примере
stream-ciphered struct < uint8 field1; uint8 field2; digitally-signed opaque < uint8 field3; uint8 field4; >; > UserType;
содержимое внутренней структуры (поля field3 и field4) служит в качестве входной информации для алгоритма цифровой подписи/хэширования, а структура в целом кодируется с использованием потокового шифрования. Размер этой структуры будет равен сумме размеров полей field1 и field2 (2 байта), поля алгоритма хеширования и подписи (2 байта), поля размера подписи (2 байта) и самой цифровой подписи. Это значение можно вычислить, поскольку алгоритм и ключ, используемые для цифровой подписи, известны до кодирования или декодирования этой структуры.
4.8. Константы
Для целей спецификации путем декларирования символа желаемого типа и присваивания ему значения могут использоваться типизованные константы. Предопределенные типы (opaque, векторы переменной длины и структуры, содержащие тип opaque) не могут использоваться в качестве присваиваемых константам значений. Поля многоэлементной структуры или вектора не могут быть пропущены.
struct < uint8 f1; uint8 f2; >Example1; Example1 ex1 = ; /* присваивание f1 = 1, f2 = 4 */
5. HMAC и псевдослучайная функция
Для многих операций уровней TLS R ecord и TLS H andshake требуется код MAC 8 , позволяющий защитить целостность сообщений, – сигнатура неких данных, защищенная ключом. Определенные в этом документе шифронаборы используют конструкцию, известную, как HMAC [HMAC], работающую на основе хэш-функции. Другие шифронаборы при необходимости могут определять свои конструкции MAC.
Кроме того, требуется конструкция для преобразования секретов в блоки данных для генерации или проверки пригодности ключей. Такая псевдослучайная функция PRF принимает на входе секрет, затравку (seed) и идентифицирующую метку, выдавая результат произвольного размера.
В этом разделе мы определяем PRF на основе HMAC. Эта PRF с хэш-функцией SHA-256 применяется для всех шифронаборов, определенных в этом документе и документах TLS, выпущенных во время согласования TLS 1.2. Новые шифронаборы должны явно указывать PRF и в общем случае следует применять TLS PRF с SHA-256 или более сильной стандартной функцией.
Определим сначала функцию преобразования данных P_hash(secret, data), которая использует одну хэш-функцию для создания на базе секрета и затравки блока данных произвольного размера:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + .
где знак + означает конкатенацию.
Значения A() определяются следующим образом
A(0) = seed A(i) = HMAC_hash(secret, A(i-1))
Функция P_hash может итеративно применяться столько раз, сколько потребуется для генерации нужного объема данных. Например, если будет применяться функция P_SHA256, для создания 80 байтов данных ее можно вызвать 3 раза (до A(3)), что даст 96 байтов на выходе и последние 16 байтов финальной итерации отбросить для создания выходного блока размером 80 байтов.
TLS PRF создается путем применения P_hash к секрету, как показано ниже
PRF(secret, label, seed) = P_(secret, label + seed)
Метка представляет собой строку символов ASCII. Ее следует включать в неизменном виде без байта размера или завершающего null-символа. Например, метка slithy toves будет при хэшировании использоваться, как последовательность байтов:
73 6C 69 74 68 79 20 74 6F 76 65 73
6. Протокол TLS Record
Протокол TLS Record включает несколько уровней. На каждом уровне сообщение может включать поля размера, описания и содержимого. Протокол Record принимает сообщения для передачи, фрагментирует данные в блоки нужного размера с возможным их сжатием, применяет MAC, шифрует и передает результат. Принятые данные расшифровываются, проверяются 9 , декомпрессируются (при необходимости) и собираются заново из фрагментов, после чего передаются клиенту на вышележащий уровень.
В этом документе описаны 4 клиента данного протокола – протокол согласования (handshake), протокол сигнализации (alert), протокол смены шифра (change cipher spec) и прикладной протокол (application data). Для поддержки расширений TLS протоколом R ecord могут поддерживаться дополнительные типы записей. Значения для новых типов выделяются агентством IANA в реестре Content Type Registry, как описано в разделе 12.
Реализациям недопустимо передавать записи типов, не определенных в этом документе, если не было согласовано то или иное расширение. Если реализация TLS получает запись неизвестного типа, она должна возвращать в ответ сигнал unexpected_message.
Любой протокол, предназначенный для работы на основе TLS, должен разрабатываться с учетом возможных атак на него. На практике это означает, что разработчики таких протоколов должны принимать во внимание, какие свойства защиты протокол TLS обеспечивает и не обеспечивает (и на них нельзя полагаться).
Отметим, что поля типа и размера записи не защищены с помощью шифрования. Если сама эта информация является конфиденциальной, разработчики приложения могут принять те или иные меры (заполнение, зашумление трафика) для минимизации утечек.
6.1. Состояния соединений
Состояние соединения TLS представляет собой рабочую среду протокола TLS Record. Оно задает алгоритмы сжатия, шифрования и MAC. Кроме того, известны параметры этих алгоритмов – секрет MAC и ключи шифрования больших объемов данных для соединения в направлениях чтения и записи. Логически всегда присутствуют 4 состояния — текущие состояния для чтения и записи, а также состояния для ожидаемых чтения и записи. Все записи (record) обрабатываются в текущих состояниях чтения и записи. Параметры безопасности для ожидающих состояний могут устанавливаться протоколом TLS Handshake, а Change Cipher Spec может избирательно переводить ожидающее состояние в текущее (в этом случае текущее состояние удаляется и заменяется ожидающим, а новое ожидающее состояние инициализируется пустым). Недопустимо делать текущим состояние, которое не было инициализировано с параметрами защиты. Изначальное текущее состояние всегда задает отсутствие шифрования, компрессии и MAC.
Параметры защиты для состояний чтения и записи TLS Connection задаются приведенными ниже значениями.
connection end — конечная точка
Показывает, является ли данная точка «клиентом» или «сервером» в этом соединении.
PRF algorithm — алгоритм псевдослучайной функции 
Алгоритм, используемый для генерации ключей из первичного секрета (см. раздел 5 и параграф 6.3).
bulk encryption algorithm — алгоритм шифрования больших объемов данных
Алгоритм, который будет использоваться для шифрования основного объема данных. Данная спецификация включает размер ключа для этого алгоритма, тип шифра (блочный, потоковый или AEAD), размер блока (для блочных шифров) и размеры явных или неявных векторов инициализации (или nonce).
MAC algorithm — алгоритм MAC
Алгоритм, используемый для аутентификации сообщений. Данная спецификация включает размер хэш-значения, возвращаемого алгоритмом MAC.
compression algorithm — алгоритм сжатия
Алгоритм, используемый для сжатия данных. Спецификация должна включать всю информацию, требуемую для сжатия.
master secret — первичный секрет
48-байтовое секретное значение, известное обеим сторонам соединения.
client random — случайное значение клиента
32-битовое случайное число, предоставляемое клиентом.
server random — случайное значение сервера
32-битовое случайное число, предоставляемое сервером.
Эти параметры определяются на языке представления следующим образом:
enum < server, client >ConnectionEnd; enum < tls_prf_sha256 >PRFAlgorithm; enum < null, rc4, 3des, aes >BulkCipherAlgorithm; enum < stream, block, aead >CipherType; enum < null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, hmac_sha512>MACAlgorithm; enum < null(0), (255) >CompressionMethod; /* Могут быть добавлены алгоритмы, указанные в CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm и MACAlgorithm. */ struct < ConnectionEnd entity; PRFAlgorithm prf_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm; CipherType cipher_type; uint8 enc_key_length; uint8 block_length; uint8 fixed_iv_length; uint8 record_iv_length; MACAlgorithm mac_algorithm; uint8 mac_length; uint8 mac_key_length; CompressionMethod compression_algorithm; opaque master_secret[48]; opaque client_random[32]; opaque server_random[32]; >SecurityParameters;
Уровень записей будет использовать параметры безопасности для генерации перечисленных ниже 6 элементов ( некоторые элементы используются не всеми шифрами и могут быть пустыми ).
client write MAC key server write MAC key client write encryption key server write encryption key client write IV server write IV
Клиентские параметры записи используются сервером при получении и обработке записей, а серверные используются клиентом. Алгоритм генерации указанных элементов из параметров защиты описан в параграфе 6.3.
После того как установлены параметры защиты и созданы ключи, состояния соединений могут быть установлены и сделаны текущими. Текущие состояния должны обновляться для каждой обработанной записи. Каждое состояние соединения включает перечисленные ниже элементы.
compression state — состояние компрессии
Текущее состояние алгоритма сжатия.
cipher state — состояние шифра
Текущее состояние алгоритма шифрования, включающее запланированный ключ для данного соединения. Для потоковых шифров этот элемент будет содержать информацию, требуемую для продолжения шифрования или дешифрования потока данных.
MAC secret — секрет MAC
Секретное значение MAC для данного соединения (см. выше).
sequence number — порядковый номер
Для каждого соединения поддерживается порядковый номер (раздельно для состояний чтения и записи). Порядковый номер должен устанавливаться в 0 при переходе соединения в активное состояние. Номер представляет собой значение типа uint64 и не может быть больше 2 64 -1. При достижении максимального значения порядковый номер не сбрасывается в 0. Если реализации TLS требуется сбросить номер при достижении максимального значения, она должна заново выполнить согласования. Порядковые номера увеличиваются после каждой записи (первая запись для конкретного соединения должна использовать порядковый номер 0).
6.2. Уровень записи
Уровень TLS Record принимает неразобранные данные от вышележащих уровней в непустых блоках произвольного размера.
6.2.1. Фрагментация
Уровень записи фрагментирует информационные блоки в записи TLSPlaintext, передающие данные размером до 2 14 байтов. Границы клиентских сообщений не сохраняются на уровне записи (т. е., множество клиентских сообщений с одним ContentType может быть объединено в одну запись TLSPlaintext или одно сообщение может быть фрагментировано в несколько записей).
struct < uint8 major; uint8 minor; >ProtocolVersion; enum < change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) >ContentType; struct < ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; >TLSPlaintext;
type – тип
Протокол вышележащего уровня, используемый для обработки вложенного фрагмента.
 v ersion – версия
Версия протокола, который будет использоваться. Данный документ описывает протокол TLS версии 1.2, для которого номер версии имеет значение < 3, 3 >. Номер версии 3.3 сложился по историческим причинам – на основе номера , который использовался для протокола TLS v1.0 (см. Приложение A.1). Отметим, что поддерживающий разные версии TLS клиент может не знать, какая версия будет применяться, до получения им сообщения ServerHello. Обсуждение вопроса выбора номера версии для сообщений ClientHello приведено в Приложении E.
 l ength – размер 
Размер (в байтах) следующего TLSPlaintext.fragment. Значение поля не должно превышать 2 14 .
fragment – фрагмент 
Данные приложения. Эти данные прозрачны и трактуются, как независимый блок, с которым работает протокол вышележащего уровня, заданный полем type.
Реализациям недопустимо передавать фрагменты нулевого размера для типов Handshake, Alert и ChangeCipherSpec. Фрагменты нулевого размера типа Application можно передавать, поскольку они потенциально могут препятствовать анализу трафика.
Примечание. Возможно чередование данных разных типов уровня TLS Record. Данные приложений в общем случае при передаче имеют более низкий приоритет по сравнению с другими типами информации. Однако записи должны доставляться в сеть в том же порядке, в котором они защищались уровнем записи. Получатели должны принимать и обрабатывать чередующийся трафик прикладного уровня в течение процессов согласований, следующих за первым согласованием для данного соединения.
6.2.2. Сжатие и декомпрессия записей
Все записи сжимаются с использованием алгоритма компрессии, определенного для текущего состояния сессии. Во всех случаях имеется один активный алгоритм сжатия, однако в начальный момент используется пустой алгоритм CompressionMethod.null. Алгоритм сжатия преобразует структуру TLSPlaintext в другую структуру TLSCompressed. Функция сжатия инициализируется с принятой по умолчанию информацией о состоянии после того, как состояние соединения становится активным. Алгоритмы сжатия для TLS описаны в [RFC3749].
Компрессия не должна приводить к потерям и увеличивать размер сжимаемых данных более, чем на 1024 байта. Если функция декомпрессии встречает фрагмент TLSCompressed.fragment, который она будет декомпрессировать в размер, превышающий 2 14 байтов, она должна выдавать сообщение о критической ошибке при декомпрессии.
struct < ContentType type; /* то же, что TLSPlaintext.type */ ProtocolVersion version;/* то же, что TLSPlaintext.version */ uint16 length; opaque fragment[TLSCompressed.length]; >TLSCompressed;
length
Размер (в байтах) следующего фрагмента TLSCompressed.fragment. Размер фрагмента не может превышать 2 14 + 1024 байтов.
fragment
Сжатое представление TLSPlaintext.fragment.
Примечание. Операция CompressionMethod.null не меняет каких-либо полей.
Примечание для разработчиков. Функция декомпрессии отвечает за то, чтобы сообщения не могли вызвать переполнения буферов.
6.2.3. Защита данных записи
Функции шифрования и MAC преобразуют структуру TLSCompressed в другую структуру TLSCiphertext. Функция расшифровки выполняет обратный процесс. Значение MAC для записи включает порядковый номер, позволяющий обнаружить недостающие, лишние или повторные сообщения.
struct < ContentType type; ProtocolVersion version; uint16 length; select (SecurityParameters.cipher_type) < case stream: GenericStreamCipher; case block: GenericBlockCipher; case aead: GenericAEADCipher; >fragment; > TLSCiphertext;
type – тип
Поле типа, идентичное TLSCompressed.type.
 v ersion – версия
Поле номера версии, идентичное TLSCompressed.version.
 l ength – размер 
Размер (в байтах) следующего фрагмента TLSCiphertext.fragment. Размер не может превышать 2 14 + 2048.
fragment – фрагмент
Зашифрованная форма TLSCompressed.fragment с кодом MAC.
6.2.3.1. Пустой или стандартный потоковый шифр
Потоковые шифры (включая BulkCipherAlgorithm.null — см. Приложение A.6) преобразуют структуры TLSCompressed.fragment в структуры TLSCiphertext.fragment и обратно.
stream-ciphered struct < opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; >GenericStreamCipher;
Значение MAC генерируется, как
MAC(MAC_write_key, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment);
где «+» означает конкатенацию.
seq_num
Порядковый номер записи.
Алгоритм хэширования, заданный полем SecurityParameters.mac_algorithm.
Отметим, что значение MAC рассчитывается до шифрования. Потоковый шифр кодирует блок целиком, включая MAC. Для потоковых шифров, не использующих вектор инициализации (таких, как RC4), состояние шифра из конца записи просто используется для следующего пакета. При использовании шифра TLS_NULL_WITH_NULL_NULL шифрование не применяется (т. е., данные не шифруются и размер MAC равен 0, что эквивалентно отказу от использования MAC). TLSCiphertext.length = TLSCompressed.length + CipherSpec.hash_size.
6.2.3.2. Блочный шифр CBC
Для блочных шифров (таких, как 3DES или AES) функции шифрования и MAC преобразуют структуры TLSCompressed.fragment в другие структуры TLSCiphertext.fragment и обратно.
struct < opaque IV[SecurityParameters.record_iv_length]; block-ciphered struct < opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; >; > GenericBlockCipher;
Значение MAC генерируется в соответствии с описанием параграфа 6.2.3.1.
IV — вектор инициализации 
Вектор инициализации (IV) следует выбирать случайно и он должен быть непредсказуемым. Отметим, что версии TLS до 1.1 не использовали поле IV и в качестве вектора инициализации применялся последний шифрованный блок предыдущей записи (CBC residue). Для предотвращения атак, описанных в [CBCATT] от этого пришлось отказаться. Для блочных шифров размер IV представляет собой размер SecurityParameters.record_iv_length, который совпадает с SecurityParameters.block_size.
padding – заполнение
Заполнение используется для выравнивания размера нешифрованн ых данных до значения, кратного размеру блока шифрования. Размер заполнения может быть произвольным (вплоть до 255 байтов), чтобы сделать значение TLSCiphertext.length кратным размеру блока. Для защиты от атак на базе анализа размера сообщений может использоваться дополнительное заполнение (сверх минимального, требуемого для выравнивания по границе блока). Каждое поле uint8 в векторе заполнения должно содержать значение размера заполнения. Получатель должен проверять значение заполнения и при несовпадении ему следует использовать сигнал bad_record_mac для индикации ошибки заполнения.
padding_length — размер заполнения
Размер заполнения должен быть таким, чтобы общий размер структуры GenericBlockCipher был кратным размеру блока шифрования. Поле размера может принимать любые значения в диапазоне от 0 до 255, включительно. Это значение определяет размер поля заполнения без учета самого поля padding_length.
Размер зашифрованных данных (TLSCiphertext.length) на 1 больше суммы значений SecurityParameters.block_length, TLSCompressed.length, SecurityParameters.mac_length и padding_length.
Пример. Если размер блока составляет 8 байтов, размер содержимого (TLSCompressed.length) – 61 байт, а размер MAC – 20 байтов, общий размер до заполнения составит 82 байта (без учета IV). Таким образом, размер заполнения для модуля 8 должен составить 6 байтов, чтобы сделать общий размер кратным 8 (размер блока). Реальный размер заполнения может составлять 6, 14, 22 и т. д., до 254. Если будет использоваться минимальное заполнение (6 байтов), каждое поле заполнения будет содержать значение 6. Таким образом последние 8 октетов GenericBlockCipher до шифрования блока будут иметь вид xx 06 06 06 06 06 06 06, где xx — последний октет MAC.
Примечание. Для блочных шифров в режиме CBC критично чтобы весь шифруемый текст записи был известен до передачи какого-либо шифротекста. В противном случае открывается возможность организации атаки, описанной в [CBCATT].
Примечание для разработчиков. Canvel с соавторами [CBCTIME] продемонстрировали атаку на заполнение CBC с синхронизацией на основе определения времени, затрачиваемого на расчет MAC. Для защиты от таких атак реализации должны обеспечить одинаковое время обработки, независимо от корректности заполнения. В общем случае лучше всего добиваться этого, рассчитывая значение MAC даже при некорректном заполнении и отвергая пакет лишь после расчета. Например, если значение заполнителя представляет некорректным, реализация может предположить, нулевой размер заполнения и рассчитать значение MAC. Это сохраняет некоторые возможности для синхронизации, поскольку время расчета MAC зависит от размера фрагмента данных, но воспользоваться такими возможностями будет гораздо сложнее, поскольку значение MAC будет рассчитываться для большого объема данных и для синхросигнала размер будет слишком мал.
6.2.3.3. Шифры AEAD
Для шифров AEAD [AEAD] (таких, как [CCM] или [GCM]) функция AEAD преобразует структуру TLSCompressed.fragment в другую структуру AEAD TLSCiphertext.fragment.
struct < opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct < opaque content[TLSCompressed.length]; >; > GenericAEADCipher;
Шифры AEAD принимают на входе один ключ, значение nonce, нешифрованный текст и «дополнительные данные» для включения в проверку подлинности, как описано в параграфе 2.1 [AEAD]. В качестве ключа используется client_write_key или server_write_key. Ключ MAC не применяется.
Каждый шифронабор AEAD должен указывать способ создания значения nonce, которое представляется операции AEAD, и размер GenericAEADCipher.nonce_explicit. Во многих случаях приемлемо использование метода неявных nonce, описанного в параграфе 3.2.1 [AEAD] с record_iv_length, совпадающим с размером явной части. В таких случаях неявную часть следует создавать из key_block, как client_write_iv и server_write_iv (см. параграф 6.3), а явная часть включается в GenericAEAEDCipher.nonce_explicit.
Нешифрованный текст представляет собой TLSCompressed.fragment.
Дополнительные данные для аутентификации, обозначенные additional_data, определяются следующим образом:
additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length;
где «+» обозначает конкатенацию.
Вывод aead_output включает результат операции шифрования AEAD . Выходной размер обычно превышает TLSCompressed.length и размер этого превышения зависит от используемого шифра AEAD. Для любого шифра AEAD недопустимо увеличение размера на выходе сверх 1024 байтов. 10 
AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, additional_data)
Для расшифровки и проверки шифр принимает на входе ключ, nonce, additional_data и шифрованное значение AEADEncrypted, возвращая на выходе расшифрованный текст или индикацию ошибки при расшифровке.
TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, AEADEncrypted, additional_data)
При отказе во время расшифровки должен генерироваться сигнал bad_record_mac.
6.3. Расчет ключей
Для протокола Record требуется алгоритм генерации ключей, требуемых для текущего состояния соединения (см. Приложение A.6), на основе параметров защиты, обеспечиваемых протоколом согласования.
Первичный секрет хэшируется в последовательность защищенных байтов, которая делится на секреты записи MAC для клиента и сервера, а также ключи записи шифрования для клиента и сервера. Эти элементы генерируются из указанной последовательности байтов в указанном порядке. Неиспользуемые значения остаются пустыми. Некоторые шифры AEAD могут дополнительно требовать векторы инициализации при записи (IV) для клиента и сервера (см. параграф 6.2.3.3).
При генерации ключей и секретов MAC первичный секрет служит источником энтропии.
Для генерации ключевого материала выполняется расчет
key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
пока не будет получен достаточный объем данных. После этого полученный блок делится, как показано ниже.
client_write_MAC_key[SecurityParameters.mac_key_length] server_write_MAC_key[SecurityParameters.mac_key_length] client_write_key[SecurityParameters.enc_key_length] server_write_key[SecurityParameters.enc_key_length] client_write_IV[SecurityParameters.fixed_iv_length] server_write_IV[SecurityParameters.fixed_iv_length]
В настоящее время client_write_IV и server_write_IV генерируются только для метода неявных nonce, как описано в параграфе 3.2.1 [AEAD].
Примечание для разработчиков. Шифронабором, которому требуется значительный объем материала, является AES_256_CBC_SHA256 — ему нужно 2 x 32 байта для ключей и 2 x 32 байтов для секретов MAC (всего 128 байтов ключевого материала).
7. Протокол TLS Handshake
TLS включает три субпротокола, которые обеспечивают партнерам возможность согласования параметров защиты для уровня записи, проведения взаимной аутентификации, установки согласованных параметров защиты и информирования об ошибках.
Протокол Handshake отвечает за согласование сессии, включающей перечисленные ниже элементы.
session identifier — идентификатор сессии
Произвольная последовательность байтов, выбранная сервером для идентификации активного или возобновляемого (resumable) состояния сессии.
peer certificate — сертификат партнера
Сертификат X509v3 [PKIX] для партнера. Этот элемент состояния может быть пустым.
compression method — метод сжатия
Алгоритм, используемый для сжатия данных перед шифрованием.
cipher spec — спецификация шифра
Задает псевдослучайную функцию (PRF), используемую для генерации ключевого материала, алгоритм шифрования больших объемов данных (типа null, AES и т. п.) и MAC (типа HMAC-SHA1). Этот параметр также определяет криптографические атрибуты типа mac_length (см. формальное определение в Приложении A.6).
master secret — первичный секрет
48-байтовое секретное значение, известное клиенту и серверу.
is resumable
Флаг возможности использования сессии для инициирования новых соединений.
Эти элементы применяются для создания параметров защиты, используемых уровнем Record для защиты данных приложения. Можно организовать множество соединений с использованием одной сессии за счет применения возможности возобновления в протоколе TLS Handshake.
7.1. Протокол смены шифра
Протокол смены шифра существует для сигнализации об изменении стратегии шифрования. Протокол включает одно сообщение, которое шифруется и сжимается в соответствии с текущим (а не ожидающим) состоянием соединения. Сообщение содержит один байт со значением 1.
struct < enum < change_cipher_spec(1), (255) >type; > ChangeCipherSpec;
Сообщения ChangeCipherSpec передаются клиентом и сервером для уведомления принимающей стороны о том, что последующие записи будут защищены с применением недавно согласованных шифров и ключей. Прием такого сообщения заставляет получателя передать на уровень Record команду незамедлительного копирования ожидающего состояния чтения в текущее состояние чтения. Сразу же после передачи такого сообщения отправитель должен дать своему уровню записи команду сделать ожидающее состояние записи текущим (см. параграф 6.1). Сообщение ChangeCipherSpec передается в процессе согласования после того, как параметры защиты согласованы, но до передачи сообщения Finished о завершении верификации.
Примечание. Если повторное согласование происходит в процессе передачи данных через соединение, взаимодействующие стороны могут продолжать передачу данных с использованием прежнего шифра CipherSpec. Однако с момента отправки ChangeCipherSpec должен использоваться новый шифр. Сторона, передавшая первой сообщение ChangeCipherSpec не знает, закончила ли другая сторона расчет нового ключевого материала (например, выполняются занимающие много времени расчеты для открытых ключей). Таким образом, может возникать небольшой промежуток времени, когда получатель должен буферизовать данные. На практике для современных машин этот промежуток явно будет очень коротким.
7.2. Протокол Alert
Одним из типов содержимого, поддерживаемого уровнем TLS Record, является сигнализация (alert). Сигнальные сообщения передают уровень важности и описание сигнала. Сообщения критического (fatal) уровня приводят к незамедлительному разрыву соединения. В этом случае другие соединения, соответствующие данной сессии, могут сохраняться, но идентификатор сессии должен быть объявлен неприемлемым (invalidated), чтобы предотвратить организацию в этой сессии новых соединений. Подобно остальным сообщениям, сигнальные сообщения шифруются и сжимаются в соответствии с текущим состоянием соединения.
enum < warning(1), fatal(2), (255) >AlertLevel; enum < close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed_RESERVED(21), record_overflow(22), decompression_failure(30), handshake_failure(40), no_certificate_RESERVED(41), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), access_denied(49), decode_error(50), decrypt_error(51), export_restriction_RESERVED(60), protocol_version(70), insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), unsupported_extension(110), (255) >AlertDescription; struct < AlertLevel level; AlertDescription description; >Alert;
7.2.1. Сигнал закрытия
Клиент и сервер должны иметь общую информацию о завершении соединения во избежание атак «на отсечение» (truncation attack). Любая из сторон может инициировать обмен сообщениями о закрытии.
close_notify
Это сообщение уведомляет получателя о том, что сервер больше не будет передавать сообщений через данное соединение. Отметим, что в TLS 1.1 сбой при закрытии соединения больше не делает сессию невозобновляемой. Это отличие от TLS 1.0 обусловлено общепринятой практикой.
Любая сторона может инициировать закрытие соединения, передав сигнал close_notify. Все принятые после получения такого сигнала данные игнорируются.
Если не было передано какого-либо иного критического сигнала, к аждая сторона должна передать сигнал close_notify до закрытия пишущей стороны соединения. Другая сторона должна ответить сообщением close_notify о своей готовности и незамедлительно закрыть соединение, отбрасывая все ожидающие записи. От инициатора закрытия не требуется ожидания приема close_notify перед закрытием читающей стороны соединения.
Если использующий TLS протокол обеспечивает передачу каких-либо данных через нижележащий транспорт после закрытия соединения TLS, реализация TLS должна принять отклик close_notify до индикации прикладному уровню закрытия соединения TLS. Если прикладной протокол не переносит каких-либо дополнительных данных, а будет просто закрывать нижележащее транспортное соединение, реализация может закрыть транспорт без ожидания отклика close_notify. Никакую часть данного стандарта не следует трактовать, как требование к манере управления профилем использования TLS для транспортировки своих данных, включая организацию и разрыв соединений.
Примечание. Предполагается, что завершение соединения гарантирует доставку ожидающих данных до разрушения транспорта.
7.2.2. Сигнализация ошибок
Обработка ошибок в протоколе TLS Handshake очень проста. При обнаружении ошибки нашедшая ее сторона отправляет другой стороне сообщение. После передачи или приема сигнала о критической ошибке обе стороны незамедлительно разрывают соединение. Серверы и клиенты должны забыть идентификаторы сессий, ключи и секреты, связанные с разорванным соединением. Таким образом, любое соединение, разорванное по критическому сигналу, недопустимо возобновлять.
Всякий раз при возникновении ситуации, описанной, как критическая ошибка, реализация должна передать соответствующий сигнал до разрыва соединения. Для всех ошибок, где критический уровень не указан явно, передающая сторона может сама принимать решение о критическом или некритическом характере ошибки. Если реализация решает передать сигнал и закрыть соединение, она должна передать сигнал критического уровня.
При отправке или получении сигнала уровня warning (предупреждение) разрывать соединение обычно не требуется. Если принимающая сторона решает отказаться от этого соединения (например, после получения сигнала no_renegotiation, который она не хочет воспринимать), ей следует передать критический сигнал для разрыва соединения. По этой причине сигналы-предупреждения практически бесполезны, если передающая сторона желает сохранить соединение — в результате такие сигналы иногда опускаются. Например, если партнер решает принять сертификат с истекшим сроком действия (возможно, по указанию пользователя) и продолжить использование соединения, он обычно не передает сигнала certificate_expired.
Список определенных сигналов об ошибках приведен ниже.
unexpected_message — неожиданное сообщение
Получено неприемлемое сообщение. Этот сигнал всегда является критическим и никогда не должен возникать для сеансов между корректными реализациями.
bad_record_mac — некорректное значение MAC
Этот сигнал возвращается при получении записи с неприемлемым значением MAC. Такой сигнал также должен возвращаться при неприемлемой расшифровке TLSCiphertext – размер не кратен размеру блока или не допустимы значения заполнения. Ошибка всегда является критической и такой сигнал никогда не должен возникать для сеансов между корректными реализациями (за исключением случаев повреждения сообщений в сети).
decryption_failed_RESERVED
Этот сигнал сигнал применялся в некоторых ранних версиях TLS и его использование может открывать возможность для атак на режим CBC [CBCATT]. Использование сигнала недопустимо для соответствующих этой спецификации реализаций протокола.
record_overflow — переполнение записи
Полученная запись TLSCiphertext имеет размер, превышающий 2 14 +2048 байт, или запись была расшифрована в запись TLSCompressed, размер которой превысил 2 14 +1024 байт. Сигнал является критическим и никогда не должен возникать для сеансов между корректными реализациями (за исключением случаев повреждения сообщений в сети).
decompression_failure — отказ при декомпресси и 
Функция декомпрессии получила на входе неприемлемые данные (например, дающие на выходе избыточный размер). Сигнал является критическим.
handshake_failure — отказ при согласовании
Получение сигнала handshake_failure говорит о том, что отправитель оказался не способен согласовать приемлемый набор параметров защиты. Ошибка является критической.
no_certificate_RESERVED
Этот сигнал использовался в SSLv3, но не в TLS. Реализациям недопустимо передавать такие сигналы.
bad_certificate — некорректный сертификат
Сертификат поврежден, содержит подписи, которые не удалось проверить, и т. п.
unsupported_certificate — неподдерживаемый сертификат
Тип сертификата не поддерживается.
certificate_revoked — отозванный сертификат
Сертификат был отозван подписавшей его стороной.
certificate_expired — устаревший сертификат 
Срок действия сертификата истек.
certificate_unknown — неизвестный сертификат
Некая (не указанная) проблема, возникшая при обработке сертификата и делающая сертификат непригодным.
illegal_parameter — недопустимый параметр
При согласовании значение поля вышло за допустимые пределы или стало не совместимым с другими полями. Ошибка является критической.
unknown_ca — неизвестный удостоверяющий центр
Получена корректная цепочка сертификатов или ее часть, но сертификат не был принят по причине того, что не удалось найти сертификат CA или найденный сертификат не может быть сопоставлен с доверенными CA. Ошибка является критической.
access_denied — доступ отвергнут
Был получен корректный сертификат, но при контроле доступа отправитель принял решение об отказе от согласования. Ошибка является критической.
decode_error — ошибка декодирования
Сообщение не может быть декодировано по причине выхода того или иного поля за допустимые пределы или некорректного размера сообщения. Сигнал является критическим и никогда не должен возникать для сеансов между корректными реализациями (за исключением случаев повреждения сообщений в сети).
decrypt_error — ошибка дешифровки
Отказ криптографической операции при согласовании (включая невозможность верификации подписи, расшифровки обмена ключами или верификации сообщения Finished). Ошибка является критической.
export_restriction_RESERVED — экспортные ограничения (резерв) 
Этот сигнал использовался в некоторых ранних версиях TLS. Реализациям недопустимо передавать такие сигналы.
protocol_version — версия протокола
Версия протокола, которую клиент пытался согласовать, не поддерживается (например, старая версия отвергнута из соображений безопасности). Ошибка является критической.
insufficient_security — недостаточная защита
Возвращается вместо handshake_failure в тех случаях, когда при согласовании возник отказ по причине того, что сервер требует более защищенных шифров, нежели предложил клиент. Ошибка является критической.
internal_error — внутренняя ошибка
Внутренняя ошибка, не связанная с партнером или корректностью протокола, но не позволяющая продолжить работу (например, ошибка при выделении памяти). Ошибка является критической.
user_canceled — отказ пользователя
Согласование было отвергнуто по причинам, не связанным с протокольными ошибками. Если пользователь прервал операцию после завершения согласования, соединение лучше просто закрыть путем передачи close_notify. За этим сигналом следует передавать close_notify. Сигнал обычно служит предупреждением.
no_renegotiation — отказ от повторного согласования
Передается клиентом в ответ на запрос hello или сервером в ответ на клиентский запрос hello после первичного согласования. В любом из этих случаев обычно выполняется повторное согласование, но в тех случаях, когда такое согласование не приемлемо, получателю следует передать данный сигнал. В этот момент первичному отправителю следует решить вопрос о продолжении работы с данным соединением. Одним из случаев уместности такого сигнала является ситуация, когда сервер запустил процесс для выполнения запроса — процесс при старте мог получить параметры защиты (размер ключа, аутентификация и т. п.), изменить которые после запуска достаточно сложно. Сигнал всегда служит предупреждением.
unsupported_extension — неподдерживаемое расширение 
Этот сигнал передается клиентом, получившим от сервера сообщение, содержащее расширение, которое этот клиент не может поместить в свое сообщение hello. Ошибка является критической.
Новые значения для сигналов выделяются агентством IANA, как описано в разделе 12.
7.3. Обзор протокола Handshake
Криптографические параметры состояния сессии задаются с использованием протокола TLS Handshake, работающего «поверх» уровня TLS Record. Когда клиент и сервер TLS начинают взаимодействие, они согласуют номер версии протокола, выбирают криптографические алгоритмы, могут выполнить взаимную аутентификацию, а также создают общие секреты с помощью шифрования на базе открытых ключей.
Протокол TLS Handshake включает следующие этапы:

обмен сообщениями hello для согласования алгоритмов, обмена случайными значениями и проверки возобновляемости сессии;
обмен требуемыми криптографическими параметрами, позволяющими клиенту и серверу согласовать предварительный секрет (premaster secret);
обмен сертификатами и криптографической информацией для обеспечения возможности взаимной аутентификации клиента и сервера;
генерация первичного секрета (master secret) из предварительного (premaster secret) и переданных друг другу случайных значений;
предоставление параметров безопасности уровню записи;
предоставление клиенту и серверу возможности проверить, что партнер выбрал такие же параметры безопасности, а согласование происходило без вмешательства злоумышленников.

Отметим, что вышележащим протоколам не следует чересчур доверять TLS в плане согласования сторонами наиболее строго из возможных вариантов — существует множество способов, когда перехват с участием человека (MITM 11 ) может использоваться для снижения уровня защиты вплоть до минимально возможного. Протокол рассчитан на минимизацию риска, но атаки все равно возможны — например, атакующий может блокировать доступ к порту, через который работает служба защиты и попытаться вынудить партнеров организовать соединение без проверки подлинности. Фундаментальным правилом является необходимость понимать на верхних уровнях реальные потребности в защите и никогда не передавать данные через канал, не обеспечивающий требуемого уровня защиты. Протокол TLS является защищенным, поскольку любой из шифров обеспечивает заявленный уровень защиты — если вы согласовали использование алгоритма 3DES с обменом RSA для 1024-битовых ключей с хостом, чей сертификат был подтвержден, вы может быть уверенными в защите.
Эти цели могут быть достигнуты с помощью протокола согласования (handshake), работу которого кратко можно описать следующим образом — клиент отправляет приветственное сообщение ClientHello, на которое сервер отвечает своим приветствием ServerHello или, при возникновении критической ошибки, соединение будет разорвано. Сообщения ClientHello и ServerHello служат для организации защищенного соединения между сторонами. При обмене этими сообщениями организуются следующие атрибуты: Protocol Version, Session ID, Cipher Suite, Compression Method. В дополнение к ним происходит генерация случайных значений ClientHello.random и ServerHello.random с обменом ими.
Для реального обмена ключами используется до 4 сообщений — Certificate и ServerKeyExchange от сервера, Certificate и ClientKeyExchange от клиента. Может быть создан новый метод обмена ключами путем задания формата для этих сообщений и определения способа использования, который позволит согласовать между клиентом и сервером общий (shared) секрет. Этот секрет должен быть достаточно длинным – определенные к настоящему моменту методы обмена ключами поддерживают секреты размером от 46 байтов.
Вслед за сообщениями hello сервер будет отправлять свой сертификат в сообщении Certificate, если нужна аутентификация. Кроме того, может быть передано сообщение ServerKeyExchange, если оно требуется (например, если сервер не имеет сертификата или сертификат предназначен только для подписи). Если сервер аутентифицирован, он может запросить у клиента сертификат, когда это приемлемо для выбранного шифронабора. После этого сервер будут передавать сообщение ServerHelloDone, показывающее, что фаза сообщений hello при согласовании завершена. Далее сервер ждет отклика клиента. Если сервер передал сообщение CertificateRequest, клиент должен вернуть ему свой сертификат в сообщении Certificate. Далее передается сообщение ClientKeyExchange, содержимое которого будет зависеть от выбранного с помощью ClientHello и ServerHello алгоритма шифрования с открытыми ключами. Если клиент представил сертификат с возможностью подписи, передается сообщение CertificateVerify с цифровой подписью для явной проверки владения секретным ключом сертификата.
Клиент Сервер ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* [ChangeCipherSpec] Данные приложений
* необязательное сообщение
Рисунок 1. Поток сообщений при полном согласовании.
После этого клиент передает сообщение ChangeCipherSpec и копирует ожидающее значение Cipher Spec в текущее значение Cipher Spec. Клиент после этого незамедлительно передает сообщение Finished с использованием новых алгоритмов, ключей и секретов. В ответ сервер будет передавать свое сообщение ChangeCipherSpec, переносить ожидающее значение Cipher Spec в текущее и передавать сообщение Finished с использованием нового Cipher Spec. На этом согласование завершается — клиент и сервер могут начать обмен данными приложений (см. Рисунок 1). Данные приложений недопустимо передавать до завершения первого согласования (до выбора шифронабора, отличного от TLS_NULL_WITH_NULL_NULL).
Примечание. Для предотвращения передачи ChangeCipherSpec в одной записи вместе с другими фрагментами согласования для ChangeCipherSpec выделен особый тип содержимого TLS — эти сообщения не относятся к согласующим сообщениям TLS. Во избежание простоев на соединениях сообщения ChangeCipherSpec передаются клиентом и сервером 12 .
Для случаев, когда клиент и сервер принимают решение возобновить предыдущую сессию или дублировать существующую (вместо согласования новых параметров защиты), поток сообщений описан ниже.
Клиент передает сообщение ClientHello, используя Session ID возобновляемой сессии. Сервер проверяет соответствие этой сессии своему кэшу. Если в кэше найден соответствующий идентификатор сессии и сервер согласен на ее возобновление в указанном состоянии, он передает сообщение ServerHello с таким же значением Session ID. Далее клиент и сервер должны передать сообщения о смене шифра и сразу же перейти к сообщениям о завершении. На этом восстановление сессии завершается, клиент и сервер могут обмениваться данными прикладных уровней (см. Рисунок 2). Если значение Session ID не найдено, сервер генерирует новый идентификатор, после чего клиент и сервер TLS выполняют полную процедуру согласования.
Клиент Сервер ClientHello --------> ServerHello [ChangeCipherSpec] Данные приложений Данные приложений
Рисунок 2. Поток сообщений для сокращенного согласования.
Содержание и значимость каждого типа сообщений подробно рассматриваются в последующих параграфах.
7.4. Протокол согласования параметров
Протокол TLS Handshake является одним из определенных клиентов вышележащего уровня для протокола TLS Record. Этот протокол служит для согласования параметров защиты сессии. Сообщения Handshake передаются уровню TLS Record, где они инкапсулируются в одну или несколько структур TLSPlaintext, обрабатываемых и передаваемых в соответствии с текущим активным состоянием сессии.
enum < hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) >HandshakeType; struct < HandshakeType msg_type; /* тип сообщения */ uint24 length; /* число байтов в сообщении */ select (HandshakeType) < case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; >body; > Handshake;
Сообщения протокола согласования представлены ниже в том порядке, в котором они должны передаваться; нарушение порядка сообщений является критической ошибкой. Необязательные сообщения могут быть опущены. Описанный порядок имеет исключение – сообщение Certificate при согласовании используется дважды (одно от сервера клиенту, второе обратно), но описано только для первого случая. С ообщения Hello Request могут передаваться в любой момент, но клиенту следует игнорировать такие сообщения, приходящие посреди согласования.
Значения для новых типов сообщений выделяются агентством IANA, как описано в разделе 12.
7.4.1. Сообщения Hello
Сообщения фазы приветствия используются для обмена информацией о возможностях защиты между клиентом и сервером. В начале новой сессии для уровня Record алгоритмы шифрования, хэширования и компрессии инициализируются пустыми значениями (null). Для сообщений повторного согласования используются параметры текущего состояния соединения.
7.4.1.1. Запрос приветствия
Сообщение HelloRequest может быть передано сервером в любой момент.
HelloRequest является просто уведомлением клиента о том, что ему следует начать процесс согласования. В ответ клиент в удобное для него время передает сообщение ClientHello. Это сообщение не предназначено для указания стороны, являющейся клиентом или сервером, а служит просто для инициирования нового согласования. Серверам не следует передавать HelloRequest сразу после подключения клиента. Клиент сам должен отправить в этот момент сообщение ClientHello.
Запрос приветствия будет игнорироваться клиентом, если тот в настоящий момент согласует сессию. Клиент может игнорировать такое сообщение и в тех случаях, когда он не желает заново согласовывать сессию – в таких случаях клиент по своему усмотрению может отвечать сигналом no_renegotiation. Поскольку согласующие сообщения имеют преимущества при передаче по сравнению с данными приложений, предполагается, что согласование начнется до того, как от клиента будет получено не более нескольких записей. Если сервер передает HelloRequest, но не получает в ответ ClientHello, он может разорвать соединение с возвратом сигнала о критической ошибке.
После передачи запроса hello серверу не следует его повторять, пока согласование не будет завершено.
struct < >HelloRequest;
Это сообщение недопустимо включать в хэши сообщений, поддерживаемые в процессе согласования и используемые в сообщениях Finished и сообщениях проверки сертификатов.
7.4.1.2. Приветствие от клиента
Когда клиент первый раз подключается к серверу, ему нужно передать сначала сообщение ClientHello. Клиент также может передать сообщение ClientHello в ответ на HelloRequest от сервера или по своей инициативе для согласования параметров защиты существующего соединения.
Сообщение ClientHello включает случайную структуру, которая будет позднее использоваться протоколом.
struct < uint32 gmt_unix_time; opaque random_bytes[28]; >Random;
gmt_unix_time
Текущее время и дата в 32-битовом формате UNIX (число секунд с полуночи 1 января 1970 по GMT без учета високосных секунд) по внутренним часам отправителя. Для базового протокола TLS корректность хода часов не имеет значения, однако протоколы вышележащих уровней могут вносить дополнительные требования. Отметим, что в силу исторических причин в имени используется обозначение GMT — предшественник современного UTC.
random_bytes
28 байтов, создаваемых защищенным генератором случайных чисел.
Сообщение ClientHello включает идентификатор сессии переменного размера. Если это значение не пусто, оно указывает сессию между этим клиентом и сервером, чьи параметры безопасности клиент желает использовать повторно. Идентификатор сессии может быть взят из прежнего соединения, текущего соединения или другого, активного в данный момент соединения. Второй вариант полезен в тех случаях, когда клиент желает лишь обновить случайные структуры и производные от них значения, а третий вариант позволяет организовать несколько независимых защищенных соединений без полного повтора протокола согласования. Эти независимые соединения могут происходить последовательно или одновременно – значение SessionID становится корректным, когда согласование завершается обменом сообщениями Finished и сохраняет корректность до удаления по сроку или в результате критической ошибки на связанном с сессией соединении. Реальное содержимое SessionID определяется сервером.
opaque SessionID;
Предупреждение. Поскольку SessionID передается без шифрования и непосредственной защиты MAC, для серверов недопустимо размещать конфиденциальную информацию в идентификаторах сессий или позволять использовать обманные идентификаторы для нарушения защиты (отметим, что содержимое согласования в целом, включая SessionID, защищено сообщениями Finished, обмен которыми происходит в конце согласования).
Список CipherSuite, передаваемый от клиента к серверу в сообщении ClientHello, содержит криптоалгоритмы, поддерживаемые клиентом в порядке их предпочтения (первым указывается самый предпочтительный). Каждый элемент CipherSuite определяет алгоритм обмена ключами, алгоритм шифрования данных (включая размер ключа), алгоритм MAC и PRF. Сервер будет выбирать один из предложенных клиентом шифронаборов или возвратит сообщение об отказе и разорвет соединение, если ни один из наборов не подходит. Если список содержит неизвестные серверу шифронаборы, сервер должен игнорировать такие наборы, обрабатывая остальные, как обычно.
uint8 CipherSuite[2]; /* селектор шифронабора */
Сообщение ClientHello включает список поддерживаемых клиентом алгоритмов компрессии, упорядоченный по предпочтению.
enum < null(0), (255) >CompressionMethod; struct < ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites; CompressionMethod compression_methods; select (extensions_present) < case false: struct <>; case true: Extension extensions; >; > ClientHello;
TLS позволяет размещать блок расширений вслед за полем compression_methods. Наличие расширений можно определить по присутствию в конце сообщения ClientHello байтов, расположенных после завершения поля compression_methods. Отметим, что этот метод обнаружения дополнительных данных отличается от обычного для TLS метода использования полей переменного размера и применяется для совместимости с определенными ранее расширениями TLS.
client_version
Версия протокола TLS, которую клиент желает использовать для взаимодействия с сервером в этой сессии. Следует использовать последнюю (с максимальным номером) из поддерживаемых клиентом версий. Для данной версии спецификации следует указывать номер версии протокола 3.3 (см. приложение E в части совместимости).
random
Генерируемая клиентом случайная структура.
session_id
Идентификатор сессии, который клиент желает использовать для данного соединения. Это поле следует оставлять пустым, если не доступно session_id или клиент хочет установить новые параметры защиты.
cipher_suites
Список криптографических опций, поддерживаемых клиентом, с указанием предпочитаемого клиентом варианта первым. Если поле session_id не пусто (запрос на восстановление сессии), этот вектор должен включать по крайней мере cipher_suite для данной сессии. Значения определены в Приложении A.5.
compression_methods
Список методов сжатия, поддерживаемых клиентом и отсортированных в порядке снижения предпочтений клиента. Если поле session_id не пусто (запрос на восстановление сессии), список должен включать по крайней мере compression_method для данной сессии. Этот вектор должен включать, а все реализации должны поддерживать метод сжатия CompressionMethod.null. Это позволяет клиенту и серверу согласовать сжатие во всех случаях.
extensions
Клиент может запросить у сервера расширенную функциональность, помещая данные в поле extensions, формат которого определен в параграфе 7.4.1.4.
Если клиент запрашивает дополнительные функции и такие функции не поддерживаются сервером, клиент может прервать согласование. Серверы должны воспринимать сообщения ClientHello как с полем extensions, так и без него и (как и для остальных сообщений) должны проверять точное соответствие объема данных в сообщении его формату — при наличии несоответствия должен отправляться критический сигнал decode_error.
После передачи клиентом сообщения ClientHello он ждет от сервера ответного сообщения ServerHello. Все прочие 13 согласующие сообщения от сервера, за исключением HelloRequest, трактуются, как критические ошибки.
7.4.1.3. Приветствие от сервера
Отправитель будет передавать это сообщение в ответ на сообщение ClientHello, если он способен поддерживать приемлемый набор алгоритмов. Если соответствия алгоритмов не обнаружено, сервер будет отвечать сигналом об отказе при согласовании.
struct < ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; select (extensions_present) < case false: struct <>; case true: Extension extensions; >; > ServerHello;
Наличие расширений может быть определено по дополнительным байтам вслед за полем compression_method в конце сообщения ServerHello.
server_version
Это поле указывает низший из предложенных клиентом и высший из поддерживаемых сервером номер версии протокола. Для данной версии спецификации используется номер 3.3 (см. Приложение E в части совместимости).
random
Эта структура генерируется сервером и должна отличаться от ClientHello.random и не зависеть от нее.
session_id
Идентификатор сессии, соответствующий данному соединению. Если значение ClientHello.session_id было непусто, сервер будет искать соответствие в своем кэше сессий. Если соответствие найдено и сервер желает организовать новое соединение с использованием указанного состояния сессии, он будет возвращать представленный клиентом идентификатор сессии. Это указывает на восстанавливаемый сеанс и требует от сторон перехода непосредственно к сообщениям Finished. В остальных случаях данное поле будет содержать значение, идентифицирующее новую сессию. Сервер может возвратить пустое поле session_id, указывая на то, что сессия не была кэширована и, следовательно, не может быть восстановлена. Если сессия восстанавливается, в ней должен использоваться согласованный ранее шифронабор. Отметим, что сервер не обязан восстанавливать любую сессию даже при наличии session_id. Клиенты должны быть готовы к выполнению полного согласования (включая новые шифры) в любой процедуре согласования.
cipher_suite
Один шифронабор, выбранный сервером из списка в ClientHello.cipher_suites. Для восстанавливаемых сессий это поле включает значение из состояния восстанавливаемой сессии.
compression_method
Один алгоритм сжатия, выбранный сервером из списка в ClientHello.compression_methods. Для восстанавливаемых сессий это поле включает значение из состояния восстанавливаемой сессии.
extensions
Список расширений. Отметим, что в этом списке могут появляться только расширения из числа предложенных клиентом.
7.4.1.4. Расширения приветствий
Формат расширения показан ниже.
struct < ExtensionType extension_type; opaque extension_data; > Extension; enum < signature_algorithms(13), (65535) >ExtensionType;
extension_type указывает конкретный тип расширения;
extension_data содержит данные, специфические для конкретного типа расширения.
Начальный набор расширений определен в документе [TLSEXT]. Список типов расширений поддерживается агентством IANA, как описано в разделе 12.
В сообщениях ServerHello недопустимо указание типов расширений, которых не было в соответствующем сообщении ClientHello. Если клиент получает в ServerHello тип расширения, который не был указан в соответствующем ClientHello, он должен прервать сог л асование , используя критический сигнал unsupported_extension.
Тем не менее, в будущем в рамках этой схемы возможно появление «ориентированных на серверы» расширений. Такое расширение (скажем, типа x) будет требовать, чтобы клиент сначала указал в сообщении ClientHello тип x с пустым полем extension_data для индикации своей поддержки этого типа расширения. Таким способом клиент позволяет серверу понять тип расширения и сервер может включить его в свое предложение.
При наличии в сообщении ClientHello или ServerHello множества типов расширений они могут указываться в любом порядке. Недопустимо указывать более одного расширения каждого типа.
Наконец, следует отметить, что расширения могут указываться как при организации новой сессии, так и в запросах на восстановление. Запрашивающий восстановление сеанса клиент в общем случае не знает, примет ли сервер этот запрос и поэтому ему следует указывать те же расширения, которые бы он передавал при организации соединения.
В общем случае спецификация каждого типа расширения должна описывать его воздействие для случаев организации новой сессии и восстановления. Большинство современных расширений TLS применимо только при организации новой сессии, а при восстановлении сессий сервер просто не будет обрабатывать эти расширения в ClientHello и не будет включать их в ServerHello. Однако для некоторых расширений при восстановлении сессий может задаваться особое поведение.
Существует ряд хитрых (и не очень) деталей взаимодействия между существующими и новыми функциями, которые могут приводить к существенному снижению общего уровня защиты. Ниже рассмотрены аспекты, которые следует принимать во внимание при разработке новых расширений.

Некоторые случаи отказа серверов от поддержки расширения связаны с ошибками, а другие просто являются отказами сервера от поддержки конкретной функции. В общем случае для первой категории следует использовать сигналы об ошибках, а во втором — поле в расширенном отклике сервера.
При разработке расширений следует принимать меры по предотвращению атак с форсированием использования (или отказа) конкретной функции путем манипуляции с сообщениями в процессе согласования. Этого следует придерживаться независимо от предполагаемого влияния функции на защиту. Зачастую достаточно факта хэширования полей, обеспечивающих входную информацию для сообщений Finished, но следует принимать особые меры предосторожности в тех случаях, когда расширения меняют назначение сообщений, передаваемых в фазе согласования. Разработчикам следует принимать во внимание факт того, что активные атакующие могут изменять, добавлять, удалять или заменять сообщения, пока согласование не будет аутентифицировано.
Технически возможно использовать расширения для изменения основных аспектов работы TLS — например, согласования шифронаборов. Делать это не рекомендуется — лучше будет определить новую версию протокола TLS — в частности, потому, что алгоритмы согласования TLS имеют специфическую защиту от атак на снижение версии, связанных с номерами версий, и возможное понижение версии должна приниматься во внимание при любом изменении устройства протокола.

7.4.1.4.1. Алгоритмы подписи
Клиент использует расширение signature_algorithms для индикации пар алгоритмов «подписи-хэширования», которые могут применяться для цифровых подписей. Поле extension_data в таких расширениях содержит значение supported_signature_algorithms.
enum < none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) >HashAlgorithm; enum < anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) >SignatureAlgorithm; struct < HashAlgorithm hash; SignatureAlgorithm signature; >SignatureAndHashAlgorithm; SignatureAndHashAlgorithm supported_signature_algorithms;
Каждое значение SignatureAndHashAlgorithm содержит одну пару «хэширование-подпись», которую клиент хочет проверить. Значения указываются в порядке снижения предпочтений.
Примечание. Поскольку не все комбинации алгоритмов хэширования и подписи могут восприниматься реализацией (например, DSA с SHA-1, но не с SHA-256), алгоритмы указываются парами.
Это поле указывает алгоритм хэширования, который может быть использован. Значения включают нехэшируемые данные (none), MD5 [MD5], SHA-1, SHA-224, SHA-256, SHA-384 и SHA-512 [SHS]. Значение none предназначено для будущих расширений на случай использования алгоритмов подписи, которые не будут требовать предварительного хэширования.
signature
Это поле указывает алгоритм подписи, который может быть использован. Значения включают анонимную подпись (anonymous), RSASSA-PKCS1-v1_5 [PKCS1] DSA [DSS] и ECDSA [ECDSA]. Значение anonymous не имеет смысла в этом контексте, но используется в параграфе 7.4.3. Недопустимо применять это значение в данном расширении.
Семантика этого расширения несколько усложняется тем, что шифронаборы указывают приемлемые алгоритмы подписи, но не указывают алгоритмов хэширования. Описание связанных с этим правил приведено в параграфах 7.4.2 и 7.4.3.
Если клиент поддерживает лишь принятые по умолчанию алгоритмы хэширования и подписи (указаны в этом параграфе), он может опустить расширение signature_algorithms. Если же клиент не поддерживает используемых по умолчанию алгоритмов или поддерживает другие алгоритмы хэширования и подписи (и хочет применять их для верификации сообщений от сервера, т. е., сертификатов и сообщений обмена ключами), он должен передать расширение signature_algorithms, указав желаемые алгоритмы.
Клиент, не передающий расширение signature_algorithms, должен выполнять перечисленное ниже:

если согласован алгоритм обмена ключами RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA или ECDHE_RSA, клиент ведет себя так, будто он передал расширение ;
если согласован алгоритм обмена ключами DHE_DSS или DH_DSS, клиент ведет себя так, будто он передал расширение ;
если согласован алгоритм обмена ключами ECDH_ECDSA или ECDHE_ECDSA, клиент ведет себя так, будто он передал расширение .

Примечание. Это отличается от TLS 1.1, где не было явных правил, но с практической точки зрения можно было предположить, что партнер поддерживает MD5 и SHA-1.
Примечание. Это расширение не имеет смысла для TLS до версии 1.2. Клиентам недопустимо предлагать его, если они используют более раннюю версию. Однако, если клиент предлагает это расширение, правила, заданные в [TLSEXT], требуют от сервера игнорировать расширение, которое он не понимает.
Серверам недопустимо передавать это расширение. Серверы TLS должны поддерживать прием этого расширения.
При восстановлении сессии это расширение не включается в ServerHello и сервер игнорирует его в ClientHello (при наличии).
7.4.2. Сертификат сервера
Сервер должен передавать сообщение Certificate всякий раз, когда согласованный метод обмена ключами использует сертификаты для проверки подлинности (это включает все определенные в данном документе методы обмена ключами, за исключением DH_anon). Это сообщение передается сразу после сообщения ServerHello.
Сообщение передает клиенту серверную цепочку сертификатов.
Сертификат должен подходить для согласованного шифронабора и всех согласованных расширений.
opaque ASN.1Cert; struct < ASN.1Cert certificate_list; > Certificate;
certificate_list
Последовательность (цепочка – chain) сертификатов X.509v3. Сертификат отправителя должен быть в списке первым. Каждый последующий сертификат должен напрямую сертифицировать своего предшественника в списке. Поскольку проверка сертификатов требует независимого распространения корневых сертификатов, самоподписанный сертификат, задающий коневой удостоверяющий центр, может быть опущен в предположении, что удаленная сторона уже имеет этот сертификат и может выполнить проверку в любом случае.
Такой же тип и структура сообщений используются для клиентских откликов на запрос сертификата. Отметим, что клиент может не передавать сертификата в ответ на запрос аутентификации от сервера, если у него нет подходящего сертификата.
Примечание. PKCS #7 [PKCS7] не используется в качестве формата векторов сертификата, поскольку расширенные сертификаты PKCS #6 [PKCS6] не применяются. Кроме того, PKCS #7 определяет SET вместо SEQUENCE, что осложняет задачу разбора.
Для передаваемых сервером сертификатов применяются перечисленные ниже правила.

Сертификаты должны быть X.509v3, если явно не согласовано иное (например, [TLSPGP]).
Конечный элемент (end entity) сертификата открытого ключа (и связанные ограничения) должен быть совместим с выбранным алгоритмом обмена ключами.

Алгоритм обмена ключами
Тип сертификата ключа
Открытый ключ RSA; сертификат должен разрешать использование ключа для шифрования (бит keyEncipherment должен быть установлен при расширенном использовании ключа).
Примечание. RSA_PSK определен в [TLSPSK].
Открытый ключ RSA; сертификат должен разрешать использование ключа для подписи (бит digitalSignature должен быть установлен при расширенном использовании ключа) со схемой подписи и алгоритмом хэширования, которые будут применяться в серверном сообщении обмена ключами.
Примечание. ECDHE_RSA определен в [TLSECC].
Открытый ключ DSS; сертификат должен разрешать использование ключа для подписи с алгоритмом хэширования, который будет применяться в серверном сообщении обмена ключами.
Ключ Diffie-Hellman ; бит keyAgreement должен быть установлен при расширенном использовании ключа .
Поддерживающий ECDH открытый ключ; этот ключ должен использовать формат кривой и точки, поддерживаемый клиентом, как описано в [TLSECC].
Поддерживающий ECDSA открытый ключ; сертификат должен разрешать использование ключа для подписи с алгоритмом хэширования, который будет применяться в серверном сообщении обмена ключами. Открытый ключ должен использовать формат кривой и точки, поддерживаемый клиентом, как описано в [TLSECC].

Расширения server_name и trusted_ca_keys [TLSEXT] используются для руководства выбором сертификата.

Если клиент представляет расширение signature_algorithms, все предоставляемые сервером сертификаты должны быть подписаны с использованием указанной в расширении пары алгоритмов хэширования и подписи. Это подразумевает, что сертификат, содержащий ключ для одного алгоритма подписи, может быть подписан с использованием другого алгоритма (например, ключ RSA подписан ключом DSA). Это отличается от стандарта TLS 1.1, который требовал использования одного алгоритма. Это также подразумевает, что алгоритмы обмена ключами DH_DSS, DH_RSA, ECDH_ECDSA и ECDH_RSA не ограничены в выборе алгоритма для подписания сертификата. Фиксированные сертификаты DH могут быть подписаны с использованием любой пары алгоритмов хэширования и подписи, появляющейся в расширении. Имена DH_DSS, DH_RSA, ECDH_ECDSA и ECDH_RSA сохраняются по историческим причинам.
Если сервер имеет множество сертификатов, он выбирает один из них на основе рассмотренных выше критериев (в дополнение к другим критериям типа конечной точки транспортного уровня, локальной конфигурации и предпочтений и т. п.). Если сервер имеет один сертификат, ему следует попытаться проверить его соответствие этим критериям.
Отметим существование сертификатов, использующих алгоритмы или комбинации алгоритмов, которые не могут в настоящее время применяться с TLS. Например, сертификат с ключом подписи RSASSA-PSS (id-RSASSA-PSS OID в SubjectPublicKeyInfo) не может использоваться, поскольку TLS не включает соответствующего алгоритма подписи.
Предполагается, что шифронаборы, задающие новые методы обмена ключами для протокола TLS, будут включать формат сертификатов и требуемую информацию о ключах.
7.4.3. Сообщение ServerKeyExchange
Это сообщение передается сразу же вслед за сообщением Certificate (или сообщением ServerHello при анонимном согласовании).
Сообщение ServerKeyExchange передается сервером только в тех случаях, когда сообщение Certificate от сервера (если оно передавалось) не содержит всех данных, позволяющих клиенту обменяться предварительным секретом (premaster secret). Это возникает при перечисленных ниже методах обмена ключами:
Не допускается передача сервером сообщения ServerKeyExchange для следующих методов обмена ключами:
Другие алгоритмы обмена ключами (типа определенных в [TLSECC]) должны указывать, передаются или нет сообщения ServerKeyExchange и при передаче сообщений определять их содержимое.
Это сообщение содержит криптографическую информацию, позволяющую клиенту обменяться предварительным секретом – с завершением обмена ключами с помощью открытого ключа Diffie-Hellman (результатом обмена будет предварительный секрет) или открытым ключом какого-либо иного алгоритма.
enum < dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa /* может быть расширенным - например, для ECDH — см. [TLSECC] */ >KeyExchangeAlgorithm; struct < opaque dh_p; opaque dh_g; opaque dh_Ys; > ServerDHParams; /* эфемерные параметры DH */
Основной модуль для операций Diffie-Hellman.
Генератор, используемый для операций Diffie-Hellman.
dh_Ys
Открытое значение Diffie-Hellman для сервера (g^X mod p).
struct < select (KeyExchangeAlgorithm) < case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct < opaque client_random[32]; opaque server_random[32]; ServerDHParams params; >signed_params; case rsa: case dh_dss: case dh_rsa: struct <> ; /* сообщение опускается для rsa, dh_dss и dh_rsa */ /* может быть расширенным - например, для ECDH — см. [TLSECC] */ >; > ServerKeyExchange;
params
Серверные параметры обмена ключами.
signed_params
Для неанонимного обмена ключами хэш соответствующих значений параметров с подписью, пригодной для использованного метода хэширования.
Если клиент предлагает расширение signature_algorithms, алгоритмы подписи и хэширования должны быть парой, указанной в этом расширении. Отметим, что здесь может возникать несогласованность. Например, клиент может предложить обмен ключами DHE_DSS, не указав ни одной пары с DSA в своем расширении signature_algorithms. Для корректного согласования сервер должен сравнивать все шифронаборы-кандидаты со списком пар в расширении signature_algorithms. Это не совсем изящно, но позволяет минимизировать изменения в устройстве шифров.
В дополнение к сказанному алгоритмы хэширования и подписи должны быть совместимы с ключом в серверном сертификате конечного элемента. Ключи RSA можно использовать со всеми разрешенными алгоритмами хэширования с учетом ограничений в сертификате, если они есть.
Поскольку подписи DSA не содержат защищенной индикации алгоритма хэширования, возникает риск подмены хэш-значения, если с одним ключом может использоваться множество таких значений. В настоящее время DSA [DSS] можно применять только с SHA-1. Предполагается, что будущие версии DSS [DSS-3] позволять применять с DSA другие алгоритмы, а также будут включать руководство по выбору алгоритма хэширования (digest), который следует применять для каждого размера ключа. В дополнение к этому будущие версии [PKIX] могут указывать в сертификатах механизмы для индикации алгоритмов хэширования, которые могут применяться с DSA.
По мере определения дополнительных шифронаборов для TLS, включающих новые методы обмена ключами, серверные сообщения обмена ключами будут передаваться тогда и только тогда, когда применяется алгоритм обмена ключами, не обеспечивающий клиента информацией, достаточной для создания предварительного секрета (premaster secret).
7.4.4. Запрос сертификата
Неанонимный сервер может запросить сертификат у клиента, если это приемлемо для выбранного шифронабора. При передаче этого сообщения оно следует непосредственно за серверным сообщением ServerKeyExchange (или, при его отсутствии, за серверным сообщением Certificate).
enum < rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20), (255) >ClientCertificateType; opaque DistinguishedName; struct < ClientCertificateType certificate_types; SignatureAndHashAlgorithm supported_signature_algorithms;14 DistinguishedName certificate_authorities; > CertificateRequest;
certificate_types
Список типов сертификатов, которые клиент может представить:
rsa_sign сертификат с ключом RSA;
dss_sign сертификат с ключом DSA;
rsa_fixed_dh сертификат со статическим ключом DH;
dss_fixed_dh сертификат со статическим ключом DH.
supported_signature_algorithms
Список пар алгоритмов хэширования и подписи, которые сервер способен проверить, отсортированный в порядке снижения уровня предпочтений.
certificate_authorities
Список различаемых имен [X501] подходящих удостоверяющих центров (certificate_authorities) в представлении DER . Эти имена могут задавать желаемое имя корневого CA или подчиненного CA; таким образом, сообщение может использоваться для описания желаемого корневого УЦ и желаемой области проверки (authorization space). Когда список certificate_authorities пуст, клиент может передать любой сертификат подходящего типа ClientCertificateType, если нет каких-либо внешних соглашений, препятствующих этому.
Взаимодействие полей certificate_types и supported_signature_algorithms несколько усложнено. Поле certificate_types пришло в TLS из SSLv3, но не было достаточным образом описано. Большая часть его функциональности перекрывается supported_signature_algorithms. Ниже перечислены применимые к этим полям правила.

Любые сертификаты, представленные клиентом, должны быть подписаны с использованием пары алгоритмов хэширования и подписи из supported_signature_algorithms.
Предоставляемые клиентом сертификаты конечных элементов (end-entity) должны содержать ключ, совместимый с certificate_types. Если это ключ подписи, он должен быть применим с той или иной парой алгоритмов хэширования и подписи из supported_signature_algorithms.
В силу исторических причин имена некоторых типов клиентских сертификатов включают использованный для подписи сертификата алгоритм. Например, в ранних версиях TLS имя rsa_fixed_dh означает сертификат, подписанный с помощью RSA и содержащий статический ключ DH. В TLS 1.2 произошел отказ от этого в пользу применения supported_signature_algorithms, а также было снято ограничение на использование алгоритмов для подписи сертификатов. Например, если сервер передает тип сертификата dss_fixed_dh и типы подписей , > , клиент может ответить сертификатом, содержащим статический ключ DH и подписанным с помощью RSA-SHA1.

Новые значения ClientCertificateType выделяются агентством IANA, как описано в разделе 12.
Примечание. Зарезервированные значения (RESERVED) не могут использоваться, они предназначены для SSLv3.
Примечание. Анонимному серверу, запрашивающему идентификацию клиента, возвращается критический сигнал handshake_failure.
7.4.5. Сообщение ServerHelloDone
Сообщение ServerHelloDone передается сервером для индикации завершения обмена ServerHello и связанными с ним сообщениями. После отправки данного сообщения сервер будет ждать отклика от клиента.
Это сообщение означает, что сервер завершил передачу сообщений для поддержки обмена ключами и клиент может начинать свою фазу обмена ключами.
При получении сообщения ServerHelloDone клиенту следует убедиться в предоставлении сервером пригодного сертификата (если это требуется) и проверить приемлемость серверных параметров hello.
struct < >ServerHelloDone;
7.4.6. Сертификат клиента
Это первое сообщение, которое клиент может передать после получения сообщения ServerHelloDone. Сообщение передается только в тех случаях, когда сервер запрашивает сертификат. Если подходящий сертификат отсутствует, клиент должен передать сообщение без сертификата (со структурой certificate_list нулевого размера). Если клиент не передает никакого сертификата, сервер может по своему усмотрению продолжить согласование без проверки подлинности клиента или ответить критическим сигналом handshake_failure. Кроме того, в случаях, когда те или иные аспекты цепочки сертификатов не приемлемы (например, не подписаны известным, доверенным CA), сервер может продолжить согласование (считая клиента неаутентифицированным) или передать критический сигнал.
Сертификаты клиента передаются с использованием структуры Certificate, определенной в параграфе 7.4.2.
Это сообщение переносит клиентскую цепочку сертификатов на сервер, который будет использовать информацию при проверке сообщения CertificateVerify (когда аутентификация сервера основывается на подписи) или расчете предварительного секрета (для неэфемерных DH). Сертификат должен подходить для алгоритма обмена ключами согласованного шифра и всех расширений при согласовании.
В частности должны выполняться перечисленные ниже условия.

Сертификат должен иметь тип X.509v3, если явно не согласовано иное (например, [TLSPGP]).
Открытый ключ сертификата конечного элемента (и связанные с ним ограничения) совместим с типами сертификатов, указанными в CertificateRequest.




Тип сертификата клиента
Тип сертификата ключа


rsa_sign
Открытый ключ RSA; сертификат должен разрешать использование ключа для подписи с применением схемы подписи и алгоритма хэширования, которые будут указаны в сообщении проверки сертификата.


dss_sign
Открытый ключ DSA; сертификат должен разрешать использование ключа для подписи с алгоритмом хэширования, который будет указан в сообщении проверки сертификата.


ecdsa_sign
Открытый ключ, поддерживающий ECDSA; сертификат должен разрешать использование ключа для подписи с применением схемы подписи и алгоритма хэширования, которые будут указаны в сообщении проверки сертификата; открытый ключ должен иметь формат кривой и точки, поддерживаемый сервером.


rsa_fixed_dh, dss_fixed_dh
Открытый ключ Diffie-Hellman ; ключ должен иметь такие же параметры, как ключ сервера .


rsa_fixed_ecdh, ecdsa_fixed_ecdh
Поддерживающий ECDH открытый ключ; этот ключ должен использовать формат кривой и точки, поддерживаемый сервером.




Если список certificate_authorities в запросе сертификата не пуст, одному из сертификатов цепочки следует быть изданным указанным у списке удостоверяющим центром (CA).
Сертификаты должны быть подписаны с использованием подходящей пары алгоритмов хэширования и подписи, как описано в параграфе 7.4.4. Отметим, что это снижает уровень ограничений на алгоритмы подписи сертификатов, присутствовавших в ранних версиях TLS.

Отметим, что как и для серверов, имеются сертификаты, которые используют алгоритмы или их комбинации, не применяемые в настоящее время с протоколом TLS.
7.4.7. Клиентское сообщение при обмене ключами
Это сообщение всегда передается клиентом и должно следовать сразу же за сообщением с сертификатом клиента, если оно передается. Если клиент не передает сертификата, данное сообщение должно быть первым сообщением клиента после получения сообщения ServerHelloDone.
С помощью этого сообщения задается предварительный секрет (premaster secret) путем прямой передачи с шифрованием RSA или передачи параметров Diffie-Hellman, позволяющих каждой стороне организовать общий секрет.
Когда клиент использует эфемерный показатель Diffie-Hellman, это сообщение содержит открытое значение Diffie-Hellman для клиента. Если клиент передает сертификат со статическим показателем DH (например, при использовании аутентификации клиента fixed_dh), это сообщение должно передаваться и должно быть пустым.
Выбор сообщений зависит от используемого метода обмена ключами. Определение KeyExchangeAlgorithm дано в параграфе 7.4.3.
struct < select (KeyExchangeAlgorithm) < case rsa: EncryptedPreMasterSecret; case dhe_dss: case dhe_rsa: case dh_dss: case dh_rsa: case dh_anon: ClientDiffieHellmanPublic; >exchange_keys; > ClientKeyExchange;
7.4.7.1. Сообщение с зашифрованным ( RSA ) предварительным секретом
Если для согласования ключей и аутентификации будет использоваться RSA, клиент генерирует 48-байтовый предварительный секрет, шифрует его с использованием открытого ключа из сертификата сервера или временного ключа RSA из серверного сообщения обмена ключами и передает результат в данном сообщении. Приведенная ниже структура является вариантом сообщения ClientKeyExchange, а не сообщением, как таковым.
struct < ProtocolVersion client_version; opaque random[46]; >PreMasterSecret;
client_version
Последняя (самая новая) версия, поддерживаемая клиентом. Это поле используется для детектирования атак на понижение версии.
random
46 случайных байтов с защищенной генерацией.
struct < public-key-encrypted PreMasterSecret pre_master_secret; >EncryptedPreMasterSecret;
pre_master_secret
Случайное значение, генерируемое клиентом и используемое для создания предварительного секрета, как описано в параграфе 8.1.
Примечание. Номер версии в PreMasterSecret должен совпадать с номером версии, предложенной клиентом в ClientHello.client_version, а не согласованной для соединения версии. Это сделано для предотвращения атак на снижение номера версии. К сожалению, многие разработчики все-таки используют согласованный номер версии, в результате чего проверка номера может приводить к отказам во взаимодействии с такими некорректными реализациями клиентов.
Реализации клиентов должны, а реализации серверов могут проверять номер версии в PreMasterSecret. Если в ClientHello.client_version указана версия TLS 1.1 или более высокая, реализация сервера должна проверить номер версии, как описано в примечании ниже. Если номер версии не выше TLS 1.0, реализации сервера следует проверить номер версии, но она может иметь конфигурационный параметр, отключающий такую проверку. Отметим, что при отрицательном результате проверки значение PreMasterSecret следует делать случайным, как описано ниже.
Примечание. Атаки, обнаруженные Bleichenbacher [BLEI] и Klima с соавторами [KPR03], можно использовать против серверов TLS, которые после расшифровки конкретного сообщения показывают факты корректного форматирования PKCS#1, наличия корректной структуры PreMasterSecret и номера версии.
Как было отмечено Klima [KPR03], этих уязвимостей можно избежать, трактуя искаженные блоки и/или несоответствие номеров версий так, чтобы эти случаи невозможно было отличить от корректно форматированных блоков RSA. Для этого выполняются перечисленные ниже действия.

Генерируется строка R из 46 случайных байтов;
сообщение расшифровывается для восстановления открытого текста M;
если заполнение PKCS#1 некорректно или размер сообщение M отличается от 48 байтов,


pre_master_secret = ClientHello.client_version || R
pre_master_secret = M
pre_master_secret = ClientHello.client_version || M[2..47].
Отметим, что явное создание pre_master_secret с ClientHello.client_version приводит к некорректному master_secret, если клиент неверно указал номер версии в исходном pre_master_secret.
Другим вариантом является трактовка несоответствия номера версии, как ошибки форматирования PKCS-1 и возврата случайного значения предварительного секрета. Для этого выполняются перечисленные ниже действия.

Генерируется строка R из 46 случайных байтов;
сообщение расшифровывается для восстановления открытого текста M;
если заполнение PKCS#1 некорректно или размер сообщение M отличается от 48 байтов,


pre_master_secret = R
premaster secret = M
иначе, если M[0..1] != ClientHello.client_version,
premaster secret = R
premaster secret = M.
Хотя практические атаки против такой конструкции не известны, Klima с соавторами [KPR03] описали некоторые теоретические атаки против нее и по этой причине рекомендуется использовать первую конструкцию.
В любом случае серверу TLS недопустимо генерировать сигнал при отказе во время обработки зашифрованного с помощью RSA предварительного секрета или получении неожиданного номера версии. Вместо этого сервер должен продолжать согласование со случайным значением предварительного секрета. Может оказаться полезным внесение в системный журнал сведений о реальной причине отказа для поиска неполадок, однако в таких случаях должны приниматься меры против утечки такой информации к злоумышленникам .
Схема шифрования RSAES-OAEP, определенная в [PKCS1], более защищена от атак Bleichenbacher. Однако для обеспечения максимальной совместимости с ранними версиями TLS в данной спецификации используется схема RSAES-PKCS1-v1_5. Информации об атаках Bleichenbacher на системы, выполняющие приведенные выше рекомендации, не известно.
Примечание для разработчиков. Зашифрованные с открытым ключом данные представляются в форме opaque-векторов (см. параграф 4.7). Таким образом, зашифрованному с помощью RSA значению PreMasterSecret в ClientKeyExchange предшествуют два байта размера. Эти байты являются избыточными в случае RSA, поскольку EncryptedPreMasterSecret является единственным элементом данных в ClientKeyExchange и размер их, следовательно, определен однозначно. В спецификации SSLv3 нет четкого описания представления данных, зашифрованных с открытым ключом, и, следовательно, многие реализации SSLv3 не включают байтов размера, помещая зашифрованные с помощью RSA данные напрямую в сообщение ClientKeyExchange.
Данная спецификация требует корректного представления EncryptedPreMasterSecret с использованием байтов размера. Получающийся в результате блок данных PDU не совместим со многими реализациями SSLv3. Разработчики, обновляющие свои программы с SSLv3, должны изменить свой код для генерации и восприятия корректного представления. Разработчикам, желающим обеспечить совместимость одновременно с SSLv3 и TLS, следует сделать поведение своих реализаций зависящим от версии протокола.
Примечание для разработчиков. Сейчас известно, что возможны удаленные атаки на TLS с использованием временных параметров ( time-based) по крайней мере для случаев размещения клиента и сервера в одной ЛВС. По этой причине реализации, применяющие статические ключи RSA, должны использовать «ослепление» RSA (blinding) или какой-либо иной метод, как описано в [TIMING].
7.4.7.2. Открытое значение Diffie-Hellman для клиента
Эта структура передает клиентское открытое значение Diffie-Hellman (Yc), если оно уже не было включено в сертификат клиента. Используемое для Yc кодирование определяется перечисляемым значением PublicValueEncoding. Эта структура является вариантом клиентского сообщения обмена ключами, а не сообщением, как таковым.
enum < implicit, explicit >PublicValueEncoding;
implicit
Если сертификат клиента уже содержит подходящий ключ Diffie-Hellman (для аутентификации fixed_dh client), значение Yc неявно уже задано и нет необходимости передавать его снова. В этом случае должно передаваться пустое сообщение ClientKeyExchange.
explicit
Yc требуется передать явно.
struct < select (PublicValueEncoding) < case implicit: struct < >; case explicit: opaque dh_Yc; > dh_public; > ClientDiffieHellmanPublic;
dh_Yc
Открытое значение Diffie-Hellman для клиента (Yc).
7.4.8. Проверка сертификата
Это сообщение служит для обеспечения явной верификации сертификата клиента. Сообщение передается только вслед за клиентским сертификатом, имеющим возможность подписи (т. е. для всех сертификатов, за исключением содержащих фиксированные параметры Diffie-Hellman). При передаче этого сообщения оно должно следовать сразу же за клиентским сообщением обмена ключами.
struct < digitally-signed struct < opaque handshake_messages[handshake_messages_length]; >> CertificateVerify;
Здесь handshake_messages указывает все согласующие сообщения, переданные или принятые, начиная с клиентского hello, вплоть (но не включая) до данного сообщения с учетом полей типа и размера сообщений. Это будет конкатенацией всех структур Handshake, определенных в параграфе 7.4 и использованных в обмене. Отметим, что это требует от обеих сторон буферизовать сообщения или рассчитывать хэш-значения для всех потенциальных алгоритмов хэширования вплоть до момента расчета CertificateVerify. Серверы могут минимизировать эти расчеты, предлагая ограниченный набор алгоритмов подписи в сообщении CertificateRequest.
Алгоритмы, используемый для хэширования и подписи, должны быть в числе тех, которые указаны в поле supported_signature_algorithms сообщения CertificateRequest. Кроме того, алгоритмы хэширования и подписи должны быть совместимы с ключом в клиентском сертификате конечного элемента. Ключи RSA могут применяться с любым разрешенным алгоритмом хэширования с учетом имеющихся в этом сертификате ограничений (если они есть).
Поскольку подписи DSA не содержат защищенной индикации алгоритма хэширования, возникает риск подмены хэш-значения, если с одним ключом может использоваться множество таких значений. В настоящее время DSA [DSS] можно применять только с SHA-1. Предполагается, что будущие версии DSS [DSS-3] позволят применять с DSA другие алгоритмы, а также будут включать руководство по выбору алгоритма хэширования (digest), который следует применять для каждого размера ключа. В дополнение к этому будущие версии [PKIX] могут указывать в сертификатах механизмы для индикации алгоритмов хэширования, которые могут применяться с DSA.
7.4.9. Сообщение Finished
Сообщение Finished всегда передается сразу же после сообщения о смене шифра для проверки успешного завершения процедур обмена ключами и аутентификации. Важно, чтобы сообщение о смене шифра было получено между другими согласующими сообщениями и сообщением Finished.
Сообщение Finished является первым сообщением, защищенным с помощью согласованных алгоритмов, ключей и секретов. Получатель сообщения Finished должен проверить пригодность его содержимого. После передачи стороной сообщения Finished, а также приема и проверки такого сообщения от партнера можно начинать передачу и прием данных через соединение.
struct < opaque verify_data[verify_data_length]; >Finished;
verify_data
PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1];
finished_label
Для сообщений Finished, переданных клиентом, это строка client finished, а для серверных сообщений Finished – server finished.
Hash обозначает хэш-значение для согласующих сообщений. Для PRF, определенной в разделе 5, значение Hash должно создаваться на основе этой PRF. Все шифронаборы, определяющие свои функции PRF, должны определять также функцию Hash для расчета сообщения Finished.
В предыдущих версиях TLS поле verify_data всегда имело размер 12 октетов, а в текущей версии TLS оно зависит от шифронабора. Если шифр не задает явно verify_data_length, используется значение verify_data_length = 12 (это относится ко всем существующим шифрам). Отметим, что это представление использует такое же кодирование, какое применялось в прежних версиях. Будущие шифронаборы могут задавать другой размер, но он во всех случаях должен быть не менее 12 байтов.
handshake_messages
Все данные из всех согласующих сообщений (кроме HelloRequest), не включая текущего. Это только данные, видимые на уровне согласования и не включающие заголовков уровня записи. Это поле является конкатенацией всех структур Handshake, определенных в параграфе 7.4 и использованных при обмене.
Если сообщение Finished не защищено ChangeCipherSpec на соответствующем этапе согласования, возникает критическая ошибка.
Значение handshake_messages включает все согласующие сообщения от клиентского hello до (но не включая) данного сообщения Finished. Оно может отличаться от handshake_messages в параграфе 7.4.8, поскольку будет включать сообщение о проверке сертификата (если оно передавалось). Кроме того, handshake_messages для сообщений Finished от клиента будет отличаться от аналогичного параметра для серверного сообщения, поскольку одно из них передается раньше другого и не будет учитывать более позднее.
Примечание. Сообщения ChangeCipherSpec, сигналы и другие типы записей не относятся к согласующим сообщениям и не включаются в расчет хэш-значения. Не учитываются и сообщения HelloRequest.
8. Криптографические расчеты
Для того, чтобы начать защиту соединения, протоколу TLS Record требуется спецификация набора алгоритмов, первичный секрет, а также случайные значения от клиента и сервера. Алгоритмы аутентификации, шифрования и MAC определяются значением cipher_suite, выбранным сервером и показанным в сообщении ServerHello. Алгоритм сжатия согласуется в сообщениях hello, они же служат для обмена случайными значениями. Остается лишь рассчитать первичный секрет.
8.1. Расчет первичного секрета
Для всех методов обмена ключами используется один алгоритм преобразования pre_master_secret в master_secret. После расчета первичного секрета (master_secret) предварительный (pre_master_secret) следует удалить из памяти.
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
Первичный секрет всегда имеет размер 48 байтов. Размер предварительного секрета зависит от метода обмена ключами.
8.1.1. RSA
При использовании RSA для аутентификации сервера и обмена ключами клиент генерирует 48-байтовое значение pre_master_secret, шифрует его с помощью открытого ключа сервера и передает серверу. Сервер использует секретный ключ для расшифровки pre_master_secret. Обе стороны могут преобразовать pre_master_secret в master_secret, как указано выше.
Цифровые подписи RSA вычисляются с использованием блоков PKCS #1 [PKCS1] типа 1. Шифрование RSA с открытым ключом выполняется с использованием блоков PKCS #1 типа 2.
8.1.2. Diffie-Hellman
Выполняется обычный расчет по методу Diffie-Hellman. Согласованный ключ (Z) используется в качестве pre_master_secret и преобразуется в master_secret, как указано выше. Ведущие байты Z, содержащие только нулевые биты, вырезаются до использования ключа Z в качестве pre_master_secret 15 .
Примечание: Параметры Diffie-Hellman задаются сервером и могут быть эфемерными или содержащимися в сертификате сервера.
9. Обязательные шифронаборы
В отсутствие профиля приложения, задающего иное, соответствующее спецификации TLS приложение должно реализовать шифронабор TLS_RSA_WITH_AES_128_CBC_SHA (см. определение в Приложении A.5).
10. Прикладной протокол
Сообщения с данными приложений передаются уровнем Record и фрагментируются, сжимаются, шифруются в соответствии с текущим состоянием соединения. Сообщения трактуются как прозрачные данные для уровня Record .
11. Вопросы безопасности
Вопросы безопасности обсуждаются на протяжении всего документа и, особенно, в Приложениях D, E и F.
12. Взаимодействие с IANA
В этом документе используются некоторые реестры, изначально созданные в [TLS1.1]. Агентство IANA обновило эти реестры в соответствии с настоящим документом. Эти реестры и правила распределения значений в них (сохранившиеся от [TLS1.1]) перечислены ниже.

TLS ClientCertificateType Identifiers. Будущие значения из диапазона 0-63 (десятичные), включительно, присваиваются по процедуре Standards Action [RFC2434]. Значения из диапазона 64-223 (десятичные), включительно, присваиваются по процедуре Specification Required [RFC2434]. Значения из диапазона 224-255 (десятичные), включительно, резервируются для частных применений [RFC2434].
TLS Cipher Suite. Будущие значения с первым байтом из диапазона 0-191 (десятичные), включительно, присваиваются по процедуре RFC 2434 Standards Action. Значения с первым байтом из диапазона 192-254 (десятичные), включительно, присваиваются по процедуре [RFC2434] Specification Required. Значения с первым байтом 255 (десятичное) резервируются для частных применений (RFC 2434 Private Use).
Этот документ добавляет новые шифронаборы на базе HMAC-SHA256, значения для которых (Приложение A.5) выделяются из реестра TLS Cipher Suite.
TLS ContentType. Будущие значения выделяются по процедуре Standards Action [RFC2434].
TLS Alert. Будущие значения выделяются по процедуре Standards Action [RFC2434].
TLS HandshakeType. Будущие значения выделяются по процедуре Standards Action [RFC2434].

Этот документ использует также реестр, созданный в [RFC4366]. Агентство IANA обновило этот реестр. Реестр и правила распределения значений в нем (сохранившиеся от [RFC4366]) указаны ниже.

TLS ExtensionType. Будущие значения выделяются по процедуре IETF Consensus [RFC2434]. Агентство IANA обновило этот реестр, включив расширение signature_algorithms и соответствующее ему значение (см. параграф 7.4.1.4).

В дополнение к этому документ определяет два новых реестра, поддерживаемых агентством IANA.

TLS SignatureAlgorithm. Реестр изначально включает значения, описанные в параграфе 7.4.1.4.1. Будущие значения из диапазона 0-63 (десятичные), включительно, присваиваются по процедуре Standards Action [RFC2434]. Значения из диапазона 64-223 (десятичные), включительно, присваиваются по процедуре Specification Required [RFC2434]. Значения из диапазона 224-255 (десятичные), включительно, резервируются для частных применений [RFC2434].
TLS HashAlgorithm. Реестр изначально включает значения, описанные в параграфе 7.4.1.4.1. Будущие значения из диапазона 0-63 (десятичные), включительно, присваиваются по процедуре Standards Action [RFC2434]. Значения из диапазона 64-223 (десятичные), включительно, присваиваются по процедуре Specification Required [RFC2434]. Значения из диапазона 224-255 (десятичные), включительно, резервируются для частных применений [RFC2434]. Этот документ использует также реестр TLS Compression Method Identifiers, определенный в [RFC3749]. Агентство IANA выделило значение 0 для метода сжатия null.

Приложение A. Протокольные константы и структуры данных
В этом разделе описаны протокольные типы и константы.
A.1. Уровень Record
struct < uint8 major; uint8 minor; >ProtocolVersion; ProtocolVersion version = < 3, 3 >; /* TLS v1.2*/ enum < change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) >ContentType; struct < ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; >TLSPlaintext; struct < ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSCompressed.length]; >TLSCompressed; struct < ContentType type; ProtocolVersion version; uint16 length; select (SecurityParameters.cipher_type) < case stream: GenericStreamCipher; case block: GenericBlockCipher; case aead: GenericAEADCipher; >fragment; > TLSCiphertext; stream-ciphered struct < opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; >GenericStreamCipher; struct < opaque IV[SecurityParameters.record_iv_length]; block-ciphered struct < opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; >; > GenericBlockCipher; struct < opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct < opaque content[TLSCompressed.length]; >; > GenericAEADCipher;
A.2. Сообщение Change Cipher Specs
struct < enum < change_cipher_spec(1), (255) >type; > ChangeCipherSpec;
A.3. Сообщения Alert
enum < warning(1), fatal(2), (255) >AlertLevel; enum < close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed_RESERVED(21), record_overflow(22), decompression_failure(30), handshake_failure(40), no_certificate_RESERVED(41), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), access_denied(49), decode_error(50), decrypt_error(51), export_restriction_RESERVED(60), protocol_version(70), insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), unsupported_extension(110), /* новое */ (255) >AlertDescription; struct < AlertLevel level; AlertDescription description; >Alert;
A.4. Протокол Handshake
enum < hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) >HandshakeType; struct < HandshakeType msg_type; uint24 length; select (HandshakeType) < case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; >body; > Handshake;
A.4.1. Сообщения Hello
A.4.2. Сообщения при аутентификации сервера и обмене ключами
opaque ASN.1Cert;17 struct < ASN.1Cert certificate_list; > Certificate; enum < dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa /* может быть расширено — например, для ECDH — см. [TLSECC] */ >KeyExchangeAlgorithm; struct < opaque dh_p; opaque dh_g; opaque dh_Ys; > ServerDHParams; /* Эфемерные параметры DH */ struct < select (KeyExchangeAlgorithm) < case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct < opaque client_random[32]; opaque server_random[32]; ServerDHParams params; >signed_params; case rsa: case dh_dss: case dh_rsa: struct <> ; /* сообщение может быть опущено для rsa, dh_dss и dh_rsa */ /* может быть расширено — например, для ECDH — см. [TLSECC] */ >18 > ServerKeyExchange; enum < rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20), (255) >ClientCertificateType; opaque DistinguishedName; struct < ClientCertificateType certificate_types; SignatureAndHashAlgorithm supported_signature_algorithms;19 DistinguishedName certificate_authorities; > CertificateRequest; struct < >ServerHelloDone;
A.4.3. Сообщения при аутентификации клиента и обмене ключами
struct < select (KeyExchangeAlgorithm) < case rsa: EncryptedPreMasterSecret; case dhe_dss: case dhe_rsa: case dh_dss: case dh_rsa: case dh_anon: ClientDiffieHellmanPublic; >exchange_keys; > ClientKeyExchange; struct < ProtocolVersion client_version; opaque random[46]; >PreMasterSecret; struct < public-key-encrypted PreMasterSecret pre_master_secret; >EncryptedPreMasterSecret; enum < implicit, explicit >PublicValueEncoding; struct < select (PublicValueEncoding) < case implicit: struct <>; case explicit: opaque DH_Yc; > dh_public; > ClientDiffieHellmanPublic; struct < digitally-signed struct < opaque handshake_messages[handshake_messages_length]; >> CertificateVerify;
A.4.4. Сообщение о завершении согласования
struct < opaque verify_data[verify_data_length]; >Finished;
A.5. Шифронаборы
Ниже определены коды шифронаборов CipherSuite, используемых в сообщениях ClientHello и ServerHello.
Значение CipherSuite определяет спецификацию шифра, поддерживаемого протоколом TLS версии 1.2.
Код TLS_NULL_WITH_NULL_NULL определяет начальное состояние соединения TLS в процессе первого согласования для данного канала, но этот шифр недопустимо согласовывать, поскольку он не обеспечивает какой-либо защиты.
CipherSuite TLS_NULL_WITH_NULL_NULL = < 0x00,0x00 >;
Приведенные ниже коды CipherSuite требуют от сервера обеспечения сертификата RSA, который может использоваться при обмене ключами. Сервер может запросить поддерживающий подписи сертификат в сообщении с запросом сертификата.
CipherSuite TLS_RSA_WITH_NULL_MD5 = < 0x00,0x01 >; CipherSuite TLS_RSA_WITH_NULL_SHA = < 0x00,0x02 >; CipherSuite TLS_RSA_WITH_NULL_SHA256 = < 0x00,0x3B >; CipherSuite TLS_RSA_WITH_RC4_128_MD5 = < 0x00,0x04 >; CipherSuite TLS_RSA_WITH_RC4_128_SHA = < 0x00,0x05 >; CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = < 0x00,0x0A >; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = < 0x00,0x2F >; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = < 0x00,0x35 >; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = < 0x00,0x3C >; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = < 0x00,0x3D >;
Приведенные ниже значения CipherSuite используются для аутентифицируемого сервером (опционально, и клиентом) механизма Diffie-Hellman. DH обозначает шифронаборы, в которых сертификат сервера включает параметры Diffie-Hellman, подписанные удостоверяющим центром (CA). DHE обозначает эфемерные значения Diffie-Hellman, где параметры Diffie-Hellman подписаны сертификатом DSS или RSA, который, в свою очередь, подписан УЦ. Используемый алгоритм подписи задается после параметра DH или DHE. Сервер может запросить у клиента сертификат RSA или DSS с возможностью подписи для его аутентификации или запросить сертификат Diffie-Hellman. Любые сертификаты Diffie-Hellman, предоставляемые клиентом, должны использовать описанные сервером параметры (группа и генератор).
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = < 0x00,0x0D >; CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = < 0x00,0x10 >; CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = < 0x00,0x13 >; CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = < 0x00,0x16 >; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = < 0x00,0x30 >; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = < 0x00,0x31 >; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = < 0x00,0x32 >; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = < 0x00,0x33 >; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = < 0x00,0x36 >; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = < 0x00,0x37 >; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = < 0x00,0x38 >; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = < 0x00,0x39 >; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = < 0x00,0x3E >; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = < 0x00,0x3F >; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = < 0x00,0x40 >; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = < 0x00,0x67 >; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = < 0x00,0x68 >; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = < 0x00,0x69 >; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = < 0x00,0x6A >; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = < 0x00,0x6B >;
Приведенные ниже коды используются для завершения анонимных коммуникаций Diffie-Hellman, в которых аутентификация сторон не выполняется. Отметим, что этот режим уязвим для MITM- атак и, следовательно, его применение ограничено — эти шифры недопустимо применять в реализациях TLS 1.2, если прикладной уровень специально не запросил использование анонимных ключей (анонимный обмен ключами может быть приемлем в отдельных случаях, например, для поддержки условного (opportunistic) шифрования без использования аутентификации или в случаях применения TLS, как части более сложного протокола, обеспечивающего иные способы проверки подлинности).
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = < 0x00,0x18 >; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = < 0x00,0x1B >; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = < 0x00,0x34 >; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = < 0x00,0x3A >; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = < 0x00,0x6C >; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = < 0x00,0x6D >;
Отметим, что использование неанонимных методов обмена ключами без реальной проверки этого обмена по сути дела равносильно анонимному обмену и требует таких же мер предосторожности. Хотя неанонимные методы обмена в общем случае включают больше расчетов по сравнению с анонимными, для обеспечения совместимости может представлять интерес отказ от отключения неанонимного обмена в тех случаях, когда прикладной уровень разрешает анонимный.
Новые коды шифронаборов выделяются агентством IANA, как описано в разделе 12.
Примечание. Значения кодов < 0x00, 0x1C >и < 0x00, 0x1D >зарезервированы для предотвращения конфликтов с шифрами на базе Fortezza в SSL3.
A.6. Параметры защиты
Параметры защиты определяются протоколом TLS Handshake и предоставляются протоколу уровня TLS Record для инициализации состояния соединения. Параметры защиты (SecurityParameters) включают:
enum < null(0), (255) >CompressionMethod; enum < server, client >ConnectionEnd; enum < tls_prf_sha256 >PRFAlgorithm; enum < null, rc4, 3des, aes >BulkCipherAlgorithm; enum < stream, block, aead >CipherType; enum < null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, hmac_sha512>MACAlgorithm; /* К алгоритмам, указанным в CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm и MACAlgorithm могут быть добавлены другие значения. */ struct < ConnectionEnd entity; PRFAlgorithm prf_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm; CipherType cipher_type; uint8 enc_key_length; uint8 block_length; uint8 fixed_iv_length; uint8 record_iv_length; MACAlgorithm mac_algorithm; uint8 mac_length; uint8 mac_key_length; CompressionMethod compression_algorithm; opaque master_secret[48]; opaque client_random[32]; opaque server_random[32]; >SecurityParameters;
A.7. Отличия от RFC 4492
В RFC 4492 [TLSECC] в протокол TLS была добавлена поддержка шифронаборов на основе эллиптических кривых (Elliptic Curve). Данный документ меняет некоторые структуры, используемые в упомянутом документе. В этом параграфе описаны требуемые изменения для реализаций, поддерживающий одновременно RFC 4492 и TLS 1.2. Разработчики TLS 1.2, не реализующие RFC 4492, могут пропустить этот параграф.
Данный документ добавляет поле signature_algorithm в элементы с цифровой подписью для идентификации алгоритмов подписи и хэширования, использованных для создания подписи. Это изменение применимо также к цифровым подписям, созданным с использованием ECDSA, позволяя применять такие подписи с алгоритмами, отличными от SHA-1, когда это совместимо с сертификатами и всеми ограничениями, которые могут быть внесены в будущих версиях [PKIX].
Как было описано в параграфах 7.4.2 и 7.4.6, ограничения на алгоритмы цифровой подписи для сертификатов больше не привязаны к шифронабору (для серверов) или ClientCertificateType (для клиентов). Таким образом, ограничения на алгоритмы подписи сертификатов, заданные в разделах 2 и 3 RFC 4492, также смягчаются. Как и в настоящем документе, ограничения на ключи в сертификатах конечных элементов сохраняются.
Приложение B. Глоссарий
Advanced Encryption Standard (AES) — усовершенствованный стандарт шифрования 
AES [AES] представляет собой широко распространенный симметричный алгоритм шифрования. Это блочный шифр с ключами размером 128, 192 или 256 битов и размером блока 16 байтов. TLS в настоящее время поддерживает только ключи размером 128 и 256 битов.
application protocol – прикладной протокол
Протокол, который обычно располагается непосредственно над транспортным уровнем (например, TCP/IP). Примерами прикладных протоколов могут служит HTTP, TELNET, FTP, SMTP.
asymmetric cipher – асимметричный шифр
См. public key cryptography.
authentication – аутентификация
Способность одного объекта проверить подлинность другого объекта.
authenticated encryption with additional data (AEAD) — аутентифицированное шифрование с дополнительными данными 
Симметричный алгоритм шифрования, обеспечивающий защиту конфиденциальности и целостности сообщений.
block cipher – блочный шифр
Блочными шифрами называются алгоритмы шифрования, работающие с текстом (данными), как с группами битов, называемыми блоками. Типичный размер блока составляет 64 или 128 битов.
bulk cipher
Симметричный алгоритм, используемый для шифрования больших объемов данных.
cipher block chaining (CBC) — сцепка шифрованных блоков 
В режиме CBC для каждого шифруемого блока сначала применяется логическая операция «Исключающее-ИЛИ» ( XOR) с предыдущим зашифрованным блоком ( или, при шифровании первого блока, с вектором инициализации – IV ). При расшифровке блок сначала дешифруется, затем применяется операция XOR с предыдущим шифрованным блоком (или IV).
certificate – сертификат
Будучи частью протокола X.509 (модель аутентификации ISO), сертификат выделяется удостоверяющим центром (Certificate Authority) и обеспечивает строгую связь между его владельцем или некими иными атрибутами и открытым ключом.
client – клиент
Объект-приложение, инициирующий соединение TLS с сервером. При этом клиент может инициировать организацию нижележащего транспортного соединения. Основное различие между клиентом и сервером заключается в их аутентификации — для сервера она используется всегда, а для клиента — по желанию.
client write key — клиентский ключ записи
Ключ, используемый для шифрования данных, записываемых клиентом.
client write MAC secret — клиентский MAC- секрет для записи 
Секретное значение, служащее для аутентификации данных, записываемых клиентом.
 c onnection – соединение
Соединением называется транспорт (в терминологии модели OSI), обеспечивающий приемлемый тип обслуживания. Для TLS используются соединения «точка-точка». Соединения являются временными, каждое соединение связано с одной сессией.
Data Encryption Standard — стандарт шифрования данных
DES [DES] является широко распространенным симметричным алгоритмом шифрования. DES представляет собой блочный шифр с 56-битовым ключом и 8-байтовыми блоками. Отметим, что в TLS при генерации ключей размер ключей DES трактуется, как 8 байтов (64 бита), но реально для защиты обеспечивается лишь 56 битов (младший бит каждого байта ключа предполагается установленным для обеспечения нечетности данного байта). DES также может работать в режиме [3DES], где для каждого блока данных используется три независимых ключа и 3-кратное шифрование. В этом случае получается размер ключа 168 битов (24 байта при генерации ключей в TLS) и обеспечивается эквивалент защиты с использованием ключей размером 112 битов .
Digital Signature Standard (DSS) – стандарт цифровой подписи 
Стандарт для цифровой подписи, включающий алгоритм цифровой подписи (Digital Signing Algorithm), одобренный NIST 20 и опубликованный в январе 2000 г. Департаментом торговли США (U.S. Dept. of Commerce) в документе NIST FIPS PUB 186-2, Digital Signature Standard [DSS]. В марте 2006 г. был опубликован новый вариант предварительного стандарта с существенными обновлениями [DSS-3].
digital signatures – цифровые подписи 
Цифровые подписи используют криптографию с открытым ключом и необратимые хэш-функции для создания подписи данных, которые требуют заверения. Цифровую подпись сложно подделать и от нее сложно отказаться.
 h andshake – согласование
Начальное согласование параметров транзакций между клиентом и сервером.
Initialization Vector (IV) – вектор инициализации 
Для блочных шифров в режиме CBC вектор инициализации используется в операции X OR с первым шифруемым блоком до его шифрования.
Блочный шифр с размером блока 64 бита, разработанный Xuejia Lai и James Massey [IDEA].
Message Authentication Code (MAC) – код аутентификации сообщения
Код аутентификации сообщения (MAC) представляет собой необратимое хэш-значение, рассчитанное с использованием содержимого сообщения и неких секретных данных. Такой код трудно подменить, не имея информации об использованных при его создании секретных данных. Код позволяет обнаружить изменение сообщения.
master secret — первичный секрет
Защищенные секретные данные, используемые для генерации ключей шифрования, секретов MAC и IV.
Защищенная функция хеширования MD5 [MD5] позволяет преобразовать поток данных произвольной длины в сигнатуру фиксированного размера (16 байтов). В результате существенного развития криптоанализа на момент публикации этого документа функция MD5 уже не считалась «безопасной» функцией хэширования.
public key cryptography – шифрование с открытым ключом
Класс криптографических методов, реализующих шифры с двумя ключами. Зашифрованное с использованием открытого ключа сообщение может быть расшифровано лишь с помощью связанного с этим открытым ключом секретного ключа. Подписи, созданные с помощью секретного ключа, можно проверить с открытым ключом.
one-way hash function – необратимая хэш-функция
Однонаправленное преобразование, которое конвертирует произвольное количество данных в хэш-значение фиксированного размера. Обращение преобразования или поиск коллизий 21 будут требовать значительных вычислительных ресурсов. Примерами однонаправленных хэш-функций являются MD5 и SHA.
Потоковый шифр, разработанный Ron Rivest. Совместимый шифр описан в [SCH].
Широко используемый алгоритм с открытым ключом, который может служить для шифрования и подписи [RSA].
salt – затравка
Несекретные случайные данные, служащие для создания экспортируемых ключей шифрования, стойких к атакам.
server – сервер
Прикладной объект, принимающий запросы на соединения от клиентов. См. также client.
session – сессия, сеанс
Сессия TLS представляет собой связь между клиентом и сервером. Сессии создаются протоколом согласования. Сессия определяет набор криптографических параметров защиты, которые могут быть общими для множества соединений. Сессии позволяют избежать ненужного согласования параметров для каждого соединения.
session identifier – идентификатор сессии
Генерируемое сервером значение, которое служит для идентификации конкретной сессии.
server write key — серверный ключ записи
Ключ, служащий для шифрования данных, записываемых сервером.
server write MAC secret — серверный секрет MAC для записи
Секретный данные, служащие для аутентификации записываемых сервером данных.
Алгоритм защищенного хэширования SHA 22 , определенный в FIPS PUB 180-2. Выходное значение имеет размер 20 байтов. Отметим, что все ссылки на SHA (без указания номера) в реальности относятся к модификации алгоритма SHA-1 [SHA].
SHA-256
256-битовый вариант алгоритма SHA, определенный в FIPS PUB 180-2. Размер выходного значения составляет 32 байта.
Протокол защищенного сокета SSL 23 [SSL3] компании Netscape. Протокол TLS основан на SSL версии 3.0.
stream cipher – потоковый шифр
Алгоритм шифрования, преобразующий ключ в (строго) криптографически защищенный поток, который применяется для логической операции XOR с незашифрованными данными .
symmetric cipher – симметричн ый шифр
См. bulk cipher на стр. 35.
Transport Layer Security (TLS) — защита транспортного уровня
Данный протокол, а также рабочая группа Transport Layer Security в IETF. См. параграф «Информация о рабочей группе» в конце документа.


Похожие публикации:

Где самые выгодные вклады в банках на 2020
Как уволить за прогулы правильно 2023 пошагово
Оплатил парковку но пришел штраф что делать москва
От какой суммы заключается договор