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

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

T. Dierks, E. Rescorla

Протокол безопасности транспортного уровня (TLS)

Версия 1.2

Запрос на комментарии 5246 (RFC 5246)

Август 2008

Часть 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 Handshake Protocol), четвертая – заключительные положения и приложения.

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

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

Официальный текст стандарта находится здесь

Общая часть

Данный документ описывает версию 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).

- Объединены в одном стандарте определение расширений TLS (TLS Extensions definition) (см. п. 7.4.1.4) и криптонаборы TLS AES (TLS 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).

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

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

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

enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

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

enum { red(3), blue(5), white(7) } Color;

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

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

enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

Имена элементов (тж. указателей) перечисления ограничены именами, перечисленными в его определении. В первом примере полная ссылка на второй элемент перечисления будет выглядеть как 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 дает ссылку на второе поле предыдущей декларации. Определения (декларации) структурных типов данных могут быть встроенными (англ. 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]];

Например:

enum { apple, orange, banana } VariantTag;

struct { uint16 number; opaque string<0..10>; /* изменяемая длина */ } 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) имеют – обозначаются как digitally-signed, stream-ciphered, block-ciphered, aead-ciphered, и public-key-encrypted, соответственно. Криптографическая обработка поля определяется путем прикрепления к нему спереди соответствующего указания ключевого слова до определения типа этого поля. На криптографические ключи влияет текущее состояние сессии (см. Секцию 6. 1).

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

struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } 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 (зашифрованный открытым ключом) является непрозрачным вектором изменяемой длины <0..2^16-1>, определяемой алгоритмом шифрования и ключом.

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

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

stream-ciphered struct { uint8 field1; uint8 field2; digitally-signed opaque { uint8 field3<0..255>; uint8 field4; }; } UserType;

4.8. Константы

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

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

Например:

struct { uint8 f1; uint8 f2; } Example1;

Example1 ex1 = {1, 4};

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

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

Для защиты целостности сообщений слой записи TLS (англ. TLS record layer) использует MAC с ключом (англ. keyed MAC). Шифронаборы (тж. криптонаборы) (англ. cipher suites), определенные в этом документе, используют основанную на хэш-функции конструкцию, известную как HMAC, описанную в [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_<hash>(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.

[20] << - оператор побитового сдвига влево. (Прим. перев.).

[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» и т. д.

Источник: https://habr.com/ru/post/573268/

Вернуться к списку

Интересные статьи

Контроль сонливости водителя и кресла с учётом женской анатомии: что нового в автомобильных технологиях безопасности?

В 1959 году компания Volvo стала оснащать свои автомобили трёхточечным ремнём безопасности, а затем поделилась этой технологией со всеми производителями. Спустя десятилет...

Каким должен быть ИТ-лидер в 2021 году. Версия Gartner

Основываясь на опыте 2020 года, эксперты Gartner выделили 10 стратегий, которым должны следовать ИТ-директора в 2021 году. Так, например, уже сейчас ИТ-лидерам необходимо оценить, чем нов...

Watermark - как сделать водяной знак в Битрикс

Есть несколько способов добавить водяной знак в Битрикс. Рассмотрим два способа.

Ошибки интернет-магазинов на 1С-Битрикс, которые снижают продажи

Получить трафик для интернет-магазина сегодня не проблема. Есть много каналов его привлечения: органическая выдача, контекстная реклама, контент-маркетинг, RTB-сети и т. д. Вопрос в том, как вы распор...

Миграции данных в Битрикс

Один из самых острых вопросов при разработке на Битрикс - это миграции базы данных. Какие же способы облегчить эту задачу есть на данный момент?