T. Dierks, E. Rescorla

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

The Transport Layer Security Protocol

Версия 1.2 (TLS 1.2)

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

Август 2008

Часть 3.2 перевода

В статье приводится продолжение перевода на русский язык стандарта IETF - RFC 5246, описывающего работу протокола безопасности транспортного уровня TLS версии 1.2. Данная часть перевода охватывает вторую половину описания работы рукопожатия TLS версии 1.2, а также завершает перевод основной части Стандарта.

Предыдущие части перевода: Часть 1, Часть 2, Часть 3.1.

Содержание

• 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

7.4.2. Серверный сертификат

Условие отправки сообщения:
Сообщение "Certificate" в обязательном порядке высылается сервером в том случае, если согласованный метод обмена ключами аутентифицирует его при помощи сертификатов (это качается всех методов, определенных в данном документе, за исключением метода DH_anon). Данное сообщение всегда следует непосредственно после сообщения "ServerHello" [1].

Содержимое сообщения:
Данное сообщение передает клиенту цепочку сертификатов сервера.

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

Структура сообщения:

opaque ASN.1Cert<1..2^24-1>;

struct {
    ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;

Параметр certificate_list
Последовательность (цепочка) сертификатов. Сертификат отправителя должен находиться первым в отправляемом списке. Каждый следующий сертификат должен напрямую сертифицировать (заверять) предшествующий ему сертификат. Так как проверка сертификатов требует того, чтобы корневые ключи (англ. root keys) распределялись независимым образом, самоподписанный (тж. самозаверенный) сертификат корневого центра сертификации (тж. удостоверяющего центра, УЦ, англ. certificate authority , CA) может быть не прикреплен к цепочке исходя из допущения того, что противоположная сторона уже имеет данный сертификат и имеет возможность проверить подписанные им сертификаты.

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

Замечание: в качестве формата для вектора, содержащего сертификат, не используется PKCS #7 [PKCS7] [2] [3], поскольку расширенные сертификаты формата PKCS #6 [PKCS6] [4] более не используются. Также PKCS #7 определяет тип данных SET [5], а не тип SEQUENCE [6], что усложняет задачу парсинга (обхода) списка сертификатов [7].

Следующие правила применяются к сертификатам, отправляемым сервером:

• Тип сертификата – обязательно X.509v3, если только не был явно согласован другой тип (напр., OpenPGP-сертификат [TLSPGP] [8]).

• Открытый ключ, содержащийся в конечном сертификате цепочки (и связанные с ним ограничения), должен быть совместимым с выбранным алгоритмом обмена ключа.

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

Если клиент указывает расширение "signature_algorithms", то все сертификаты, предоставляемые сервером, должны быть подписаны парой алгоритмов подпись/хеш, указанной в данном расширении. Обратите внимание, что при этом сертификат, содержащий ключ для одного алгоритма подписи, может быть подписан подписью, содержащей другой тип алгоритма (например, ключ RSA может быть подписан ключом DSA). Это является отличием от протокола TLS 1.1, который требовал, чтобы протоколы подписи были одинаковыми. Обратите внимание, что это также означает то, что алгоритмы обмена ключами DH_DSS, DH_RSA, ECDH_ECDSA и ECDH_RSA не ограничивают алгоритм, используемый для подписи сертификата. Постоянные DH-сертификаты [14] могут быть подписаны любым парным алгоритмом подпись/хеш, указанным в расширении. Соответственно, названия DH_DSS, DH_RSA, ECDH_ECDSA и ECDH_RSA являются историческими [15].

В том случае, если у сервера имеется несколько сертификатов, он выбирает один из них, основываясь на вышеприведенных критериях (вдобавок к таким критериям как конечная точка транспортного уровня, локальная конфигурация и локальные предпочтения, и т. д.). Если у сервера имеется только один сертификат, то серверу рекомендуется попытаться подтвердить, что его сертификат удовлетворяет всем этим критериям.

Стоит обратить внимание, что существуют сертификаты, которые используют алгоритмы и/или комбинации алгоритмов, которые не могут быть в настоящее время использованы с протоколом TLS. Например, сертификат с ключом подписи RSASSA-PSS (поле SubjectPublicKeyInfo [16] содержит OID id-RSASSA-PSS [17]) не может быть использован, так как TLS не определяет соответствующий алгоритм подписи.

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

7.4.3. Серверное сообщение обмена ключами (ServerKeyExchange)

Условие отправки сообщения:
Данное сообщение посылается сразу же после отправки серверного сообщения «Certificate» (либо после сообщения «ServerHello» в том случае, если соединение устанавливается анонимно).

Сообщение «ServerKeyExchange» высылается сервером только в том случае, если в серверном сообщении «Certificate» (если оно было послано) не содержится достаточно данных для того, чтобы позволить клиенту обменяться предварительным ключом (англ. premaster secret). Это справедливо для следующих методов обмена ключами:

• DHE_DSS

• DHE_RSA

• DH_anon

Сообщение «ServerKeyExchange» не высылается для следующих методов обмена ключами:

• RSA

• DH_DSS

• DH_RSA

Другие алгоритмы обмена ключами, например, определенные в [TLSECC], должны определять послано или нет сообщение «ServerKeyExchange»: а если послано – анализировать его содержимое.

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

Структура сообщения:

enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
            /*список может быть расширен, например, в него можно включить*/
            /* алгоритм ECDH – см. [TLSECC] */
} KeyExchangeAlgorithm;

struct {
		opaque dh_p<1..2^16-1>;
		opaque dh_g<1..2^16-1>;
		opaque dh_Ys<1..2^16-1>;
} ServerDHParams;     /*Временные (эфемерные) DH-параметры*/
/*См. тж. прим. [14]*/

dh_p
Простое число (модуль), выбранное для работы протокола Диффи-Хеллмана.

dh_g
Генератор для алгоритма Диффи-Хеллмана – первообразный корень по модулю p [18].

dh_Ys
Открытое число сервера для алгоритма Диффи-Хеллмана, которое сервер вычисляет, выбрав произвольно целое положительное число X и найдя остаток от деления g^X на p (dh_Ys = 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, and dh_rsa*/ 
                 /*сообщение не отправляется*/
            /*список может быть расширен, например, в него можно включить*/
            /* алгоритм ECDH – см. [TLSECC] */
          };
} ServerKeyExchange;

params
Серверные параметры обмена ключами.

signed_params
Подписанные серверные параметры обмена ключами (используется только при аутентифицируемом обмене ключами).

Если клиент предложил расширение "signature_algorithms", алгоритмы подписи и хеширования должны быть парой, указанной в этом расширении. Стоит обратить внимание, что на этой стадии открывается возможность для несовместимости алгоритмов. Например, клиент может предложить метод обмена ключами DHE_DSS, но не включить в расширение "signature_algorithms" пары с алгоритмом DSA. Для того, чтобы корректным образом провести согласование параметров, сервер должен сверять любой предложенный криптонабор с данными, полученными из расширения "signature_algorithms". Это может показаться грубым решением, но это – компромисс для того, чтобы минимизировать изменения в оригинальную структуру криптонаборов TLS.

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

Так как подписи на основе алгоритма DSA не содержат какого-либо защищенного указания на алгоритм хеширования, то существует риск замены хеша в том случае, если несколько алгоритмов хеширования могут быть использованы с несколькими ключами. В настоящее время (на 2008 год) ключ на основе DSA [DSS] [19] может быть использован только с алгоритмом хеша SHA-1. Ожидается, что будущие ревизии стандарта [DSS] позволят использовать вместе с алгоритмом DSA другие алгоритмы хеша, а также дадут указания на то, какие алгоритмы будут подходить для того или иного размера ключа. Кроме того, будущие ревизии [PKIX] [20] могут определить механизмы для указания сертификатами какие алгоритмы создания дайджеста [21] могут использоваться совместно с алгоритмом DSA.

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

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<1..2^16-1>;

struct {
		ClientCertificateType certificate_types<1..2^8-1>;
		SignatureAndHashAlgorithm
		supported_signature_algorithms<2..2^16-2>;
		DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

[42]

certificate_types
Список типов сертификата, которые могут быть предложены клиентом:

• rsa_sign - сертификат, содержащий ключ RSA;

• dss_sign - сертификат, содержащий ключ DSA;

• rsa_fixed_dh - сертификат, содержащий статический ключ DH;

• dss_fixed_dh - сертификат, содержащий статический ключ DH.

supported_signature_algorithms
Список пар алгоритмов хеша/подписи, которые сервер может проверить, размещенные в порядке убывания приоритета.

certificate_authorities
Список выделенных имен (англ. distinguished names) допустимых удостоверяющих центров (УЦ) дан согласно формату, определенному в [X501] [22] [23]. Сами выделенные имена приведены в формате отличительного кодирования (DER-формате) [24]. Данные выделенные имена могут определять желаемое выделенное имя для корневого УЦ или подчиненного ему УЦ; таким образом, данное сообщение может быть использовано для описания как известных корневых центров сертификации, так и для желаемого пространства авторизации. В случае, если список «certificate_authorities» является пустым, то клиент может выслать любой сертификат, соответствующий типу ClientCertificateType, если только для этого не будет каких-либо препятствующих соглашений.

Взаимодействие полей «certificate_types» и «supported_signature_algorithms» - довольно сложный процесс. Поле «certificate_types» присутствует в TLS начиная с версии SSLv3, но определение его функциональности было недостаточным. Большинство из его функций передано полю «supported_signature_algorithms» с учетом следующих правил: 

• любые предоставляемые клиентом сертификаты должны быть подписаны парой алгоритмов хеша/подписи, прописанной в поле «supported_signature_algorithms»;

• предоставляемый клиентом конечный сертификат (англ. end-entity certificate) должен содержать ключ, совместимый с типом сертификата, указанным в поле «certificate_types». Если ключ является ключом электронной подписи, то он должен поддерживать свое использование с парой алгоритмов хеша/подписи, указанной в поле «supported_signature_algorithms»;

• названия некоторых типов клиентских сертификатов по историческим соображениям содержат названия алгоритмов, используемых для подписания этого сертификата. Например, в ранних версиях TLS тип rsa_fixed_dh означал сертификат, подписанный алгоритмом RSA и содержащий статический (тж. постоянный) DH-ключ. В TLS 1.2 данная функциональность является устаревшей и заменена полем «supported_signature_algorithms», в результате чего наименование типа сертификата более не указывает на алгоритм, которым может быть подписан данный сертификат. Например, если сервер вышлет сертификат типа dss_fixed_dh и укажет типы подписей как {{sha1, dsa}, {sha1, rsa}}, то клиент может в ответ выслать сертификат, содержащий статический DH-ключ и подписанный парой алгоритмов RSA_SHA1.      

Новые значения, содержащиеся в списке «ClientCertificateType», назначаются IANA по принципам, описанным в Разд. 12.

Примечание: значения, имеющие пометку «RESERVED» использовались в SSLv3 и на данный момент не используются.

Примечание: запрос неаутентифицированного сервера на аутентификацию клиента всегда вызывает критическую ошибку «handshake_failure» (сбой рукопожатия).

7.4.5. Сообщение ServerHelloDone (завершение серверного этапа отправки hello-сообщений)

Условие отправки сообщения:
сообщение «ServerHelloDone» отправляется сервером для индикации того, что сообщение «ServerHello» и все связанные с ним сообщения были отправлены должным образом. После отправления данного сообщения сервер будет ожидать ответа от клиента.

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

После получения сообщения «ServerHelloDone» клиенту рекомендуется удостовериться в том, что сервером был отправлен действительный сертификат, если это требуется, а также проверить являются ли приемлимыми параметры серверного hello-сообщения.

Структура сообщения:

struct { } ServerHelloDone;

7.4.6. Клиентский сертификат

Условие отправки сообщения:
Данное сообщение является первым, которое может отправить клиент, после того как он получит сообщение «ServerHelloDone». Сообщение отправляется только в случае того, если сервер запросил клиентский сертификат. Если у клиента отсутствует подходящий сертификат, то он должен отправить пустое сообщение без какого-либо сертификата в нем. Таким образом, в этом случае структура «certificate_list» будет иметь нулевую длину. В свою очередь, если сервер не получит от клиента сертификат, то он по своему усмотрению может либо продолжить рукопожатие без аутентификации клиента, либо ответить сообщением о критической ошибке «handshake_failure». Также, если какой-либо сертификат в цепочке сертификатов является недействительным (напр., подписан неизвестным УЦ) сервер может на свое усмотрение либо продолжить рукопожатие (считая клиента неаутентифицированным), либо послать сообщение о критической ошибке.

Структура клиентских сертификатов описывается в п. 7.4.2 данного Стандарта и не отличается от структуры серверных сертификатов.

Содержимое сообщения:
Данное сообщение пересылает серверу клиентскую цепочку сертификации; сервер использует ее либо при проверке сообщения «CertificateVerify» (если аутентификация клиента основана на процедуре подписания), либо при вычислении предварительного секрета (для алгоритма Диффи-Хеллмана с постоянными параметрами). Сертификат должен соответствовать согласованному алгоритму обмена ключами, указанному в криптонаборе, а также согласованным расширениям.

В частности:

• тип сертификата – обязательно X.509v3, если только не был явно согласован другой тип (напр., OpenPGP-сертификат [TLSPGP]);

• открытый ключ, содержащийся в конечном сертификате цепочки (и связанные с ним ограничения), должен быть совместимым с выбранным алгоритмом обмена ключа.

Ниже дается таблица с типами клиентских сертификатов и соответствующими им типами ключей:

• Если в сообщении запроса сертификата список «certificate_authorities» не является пустым, то рекомендуется, чтобы один из сертификатов в цепочке доверия (как клиента, так и сервера) был выпущен указанным в этом списке УЦ (англ. CA).

• сертификат должен быть подписан с использованием приемлемой пары алгоритмов хеша/подписи так, как это указано в п. 7.4.4 данного Стандарта. Обратите внимание, что при этом ослаблены ограничения, накладываемые предыдущими версиями TLS.

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

7.4.7. Клиентское сообщение обмена ключами (ClientKeyExchange)

Условие отправки сообщения:
Данное сообщение всегда отправляется клиентом. Если сообщение высылается, оно должно идти непосредственно за сообщением, содержащим клиентский сертификат. Либо, если клиент не высылает свой сертификат серверу, оно должно отправляться непосредственно после того как клиент получит сообщение «ServerHelloDone».

Содержимое сообщения:
С этим сообщением передается предварительный секрет либо при прямой передаче данных, зашифрованных алгоритмом RSA, либо при передаче параметров алгоритма Диффи-Хелмана, которые позволят обеим сторонам выработать одинаковый секретный ключ.

В том случае, если клиент использует временную экспоненту Диффи-Хеллмана, то данное сообщение содержит публичное значение Диффи-Хеллмана. Если клиент отправляет сертификат, содержащий постоянную (статическую) экспоненту (например, при аутентификации клиента с параметром fixed_dh), то данное сообщение должно быть отправлено, но при этом должно быть пустым.

Структура сообщения:
Выбор сообщения зависит от того, какой был выбран метод обмена ключами. См. п. 7.4.3 для определения списка «KeyExchangeAlgorithm».

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-битный предварительный секрет, зашифровывает его при помощи открытого ключа серверного сертификата и пересылает получившийся результат серверу. Представленная нижее структура является только вариантом сообщения «ClientKeyExchange» и не является определением самого сообщения.

Структура сообщения:

struct {
          ProtocolVersion client_version;
          opaque random[46];
} PreMasterSecret; 

[25]

client_version
Последняя (самая новая) версия протокола, поддерживаемая клиентом. Данное поле используется для обнаружения атак отката версии (англ. version rollback attack).

random
46 сгенерированных случайных байт.

      struct {
          public-key-encrypted PreMasterSecret pre_master_secret;
      } EncryptedPreMasterSecret;

pre_master_secret
Случайное значение, сгенерированное клиентом и используемое для генерации основного секрета (англ. master-secret) по правилам, определенным в Разд. 8.1.

Примечание: Номер версии в структуре «PreMasterSecret» является номером, указанным клиентом в поле «ClientHello.client_version», но не версией протокола, согласованной для соединения. Данная особенность предусмотрена для предотвращения атак отката версии. К сожаления, некоторые старые реализации вместо этого указывают в «PreMasterSecret» согласованную для соединения версию протокола, что может, таким образом, привести к сбою во время взаимодействия с такими клиентскими реализациями, вызванному попыткой проверить номер версии.

Клиентские реализации всегда должны содержать в структуре «PreMasterSecret» корректную версию протокола. Если в поле «ClientHello.client_version» стоит версия TLS 1.1 или выше, то серверные реализации должны проверять версию протокола по алгоритму, указанному в примечании ниже. Если версия протокола – TLS 1.0 или ранее, серверным реализациям рекомендуется проверить версию сервера, но при этом им разрешается иметь флаг, указывающий на запрет такой проверки. Обратите внимание, что если проверка окажется неудачной, то рекомендуется, чтобы структура «PreMasterSecret» генерировалась так, как это указано ниже.

Примечание: атаки, открытые Bleichenbacher [BLEI] [26] и Klima и др. [KPR03] [27] могут применяться для атаки TLS-сервера, который при расшифровке отдельного сообщения дает информацию о том, соответствует ли его формат стандарту PKCS#1 [28], содержит ли оно действительную структуру «PreMasterSecret» и имеет ли правильный номер версии.

Klima [KPR03] сообщает о том, что этих уязвимостей можно избежать, реагируя на блоки с некорректным форматированием и/или с несовпадающими номерами версий так, чтобы эта реакция была неотличима от реакции на RSA-блоки с правильным форматированием:

1. Сгенерировать строку R длиной 46 байт.

2. Расшифровать сообщение для получения исходного текста (англ. plaintext) M.

3. Если величина дополнительных данных (тж. набивки) (англ. padding) формата PKCS#1 не является корректной, или если длина сообщения M не равна 48 байтам, то:
   pre_master_secret = ClientHello.client_version || R
   else if ClientHello.client_version <= TLS 1.0 and проверка версии явно запрещена:
   pre_master_secret = M
   else:
   pre_master_secret = ClientHello.client_version || M[2..47]

[29]

Обратите внимание, что явно строя pre_master_secret (предварительный секрет) при помощи поля ClientHello.client_version, даст в результате неверный master_secret (основной секрет) в том случае, если клиент отправит неверную версию протокола в исходном сообщении pre_master_secret.  

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

1. Сгенерировать строку R длиной 46 байт.

2. Расшифровать сообщение для получения исходного текста (англ. plaintext) M.

3. Если величина дополнительных данных (тж. набивки) (англ. padding) формата PKCS#1 не является корректной, или если длина сообщения M не равна 48 байтам, то:
   pre_master_secret = R
   else If ClientHello.client_version <= TLS 1.0, and проверка версии явно запрещена:
   premaster secret = M
   else If M[0..1] != ClientHello.client_version:
   premaster secret = R
   else:
   premaster secret = M

Хотя никаких практических атак против этой конструкции и неизвестно, но Klima и др. [KPR03] описывают некоторые теоретические атаки, рекомендуя использовать первую описанную выше конструкцию.

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

Определенная в [PKCS1] схема шифрования RSAES-OAEP более надежно защищает от атаки Блайхенбахера. Однако, для максимальной совместимости с более ранними версиями TLS данная спецификация использует схему RSAES-PKCS1-v1_5 [30]. На данный момент неизвестно о существовании каких-либо других вариантов атаки Блайхенбахера, для защиты от которых следовало бы разработать рекомендации, отличающиеся от приведённых выше.

Замечание для разработчиков: данные элемента «public-key-encrypted» представляются в виде вектора непрозрачного типа переменной длины <0..2^16-1> (см. Разд. 4.7). Таким образом, зашифрованному алгоритмом RSA значению «PreMasterSecret» в структуре «ClientKeyExchange» предшествуют два байта с длиной этого значения. Таким образом, в случае использования алгоритма RSA эти байты являются избыточными, так как поле «EncryptedPreMasterSecret» является единственным в структуре «ClientKeyExchange», поэтому длина «EncryptedPreMasterSecret» может быть недвусмысленно определена и без этих байт длины. Спецификация SSLv3 не давала четких указаний, касающихся кодировки данных элемента «public-key-encrypted» и многие реализации протокола SSLv3 не включают байты длины в «EncryptedPreMasterSecret» - они включают зашифрованные RSA данные прямиком в сообщение «ClientKeyExchange».

Данная спецификация требует, чтобы корректная кодировка структуры «EncryptedPreMasterSecret» содержала байты длины. Получаемые при этом блоки данных протокола (БДП, англ. PDU, Protocol Data Unit) [31] будут несовместимы со многими реализациями SSLv3. Разработчики, делая апгрейд своих приложений версии SSLv3, должны модифицировать свои реализации так, чтобы создавать и принимать корректно закодированные данные. Если разработчик желает, чтобы его приложение было совместимо одновременно с SSLv3 и с TLS, то он должен сделать так, чтобы поведение его реализации зависело от версии протокола, с которым оно работает.

Замечание для разработчиков: известно, что есть возможность осуществить удаленную атаку на протокол TLS на основе анализа времени ответа (тайминга) системы на различные запросы. По крайней мере, это можно осуществить, если клиент и сервер находятся в одной локальной сети (LAN). Соответственно, приложения, использующие статические RSA-ключи, должны использовать такие антитайминговые техники как RSA-ослепление (RSA-blinding) [32] и другие, описанные в [TIMING] [33].

7.4.7.2. Открытое число клиента в алгоритме Диффи-Хеллмана

Содержимое сообщения:
Данная структура доставляет открытое значение алгоритма Диффи-Хелламана (Yc) [34] от клиента серверу в том случае, если оно еще не было включено в клиентский сертификат. Используемые варианты для представления Yc задаются перечислением (enum ) «PublicValueEncoding». Представленная далее структура является только вариантом сообщения «ClientKeyExchange» и не является определением самого сообщения.

Структура сообщения:

			enum {implicit, explicit } PublicValueEncoding;
     	/* неявное и явное представление */
     
      struct {
          select (PublicValueEncoding) {
              case implicit: struct { };
              case explicit: opaque dh_Yc<1..2^16-1>;
          } dh_public;
      } ClientDiffieHellmanPublic;

implicit
Если клиент выслал сертификат, уже содержащий подходящий ключ Диффи-Хеллмана (для параметров аутентификации fixed_dh), то Yc выражено неявно (англ. implicit) и его не требуется высылать повторно. В этом случае клиентское сообщение обмена ключами высылается, но оно должно быть пустым.

explicit
Yc необходимо высылать, так как в сертификата клиента данного значения не имеется.

dh_Yc
Открытое число клиента для алгоритма Диффи-Хеллмана.

7.4.8. Сообщение о проверке сертификата (CertificateVerify)

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

Структура сообщения:

      struct {
           digitally-signed struct {
               opaque handshake_messages[handshake_messages_length];
           }
      } CertificateVerify;

Здесь поле «handshake_messages» относится ко всем сообщениям рукопожатия как отправленным, так и полученным начиная с клиентского hello-сообщения, и заканчивая, но, не включая, данное сообщение, включая типы и длины полей во всех сообщениях рукопожатия. По своей природе оно является конкатенацией всех структур рукопожатия (определенных в Разд. 7.4), обмен которыми уже был осуществлен. Обратите внимания, что это требует того, чтобы обе стороны рукопожатия записывали эти сообщения в буфер или вычисляли значения их хеш-функций, используя все потенциально могущие быть использованы алгоритмы хеширования. Сервера могут ограничить такие вычисления, указав ограниченный набор функций хеширования в своем сообщении «CertificateRequest».

Алгоритмы хеширования и подписи, задействованные для функции подписания, должны быть прописаны в поле «supported_signature_algorithms» сообщения «CertificateRequest». В добавок к этому, алгоритмы хеша и подписи должны быть совместимы с ключом, содержащимся в конечном сертификате клиента. Ключи RSA могут использоваться с любым разрешенным алгоритмом хеша в соответствии с ограничениями сертификата, если такие ограничения присутствуют.

Так как подписи на основе алгоритма DSA не содержат какого-либо защищенного указания на алгоритм хеширования, то существует риск замены хеша в том случае, если несколько алгоритмов хеширования могут быть использованы с несколькими ключами. В настоящее время (на 2008 год) ключ на основе DSA [DSS] может быть использован только с алгоритмом хеша SHA-1. Ожидается, что будущие ревизии стандарта [DSS] позволят использовать вместе с алгоритмом DSA другие алгоритмы хеша, а также дадут указания на то, какие алгоритмы будут подходить для того или иного размера ключа. Кроме того, будущие ревизии [PKIX] могут определить механизмы для указания сертификатами какие алгоритмы создания дайджеста могут использоваться совместно с алгоритмом DSA.

7.4.9. Сообщение Finished

Условие отправки сообщения:
Сообщение «Finished» всегда высылается сразу же после сообщения о смене параметров шифрования (ChangeCipherSpec) для проверки того, что операции обмена ключами и аутентификации прошли успешно. Существенно важно, чтобы сообщение «ChangeCipherSpec» было получено после всех остальных сообщений рукопожатия и перед сообщением «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
Строковое значение - аргумент для PRF. Значение строки для клиентских сообщений «Finished» - «client finished». Значение строки для серверных сообщений «Finished» - «server finished».  

Hash
Значение хеш-функции (дайджест) для всех сообщений рукопожатия. Для псевдослучайной функции (PRF), определенной в Разделе 5, дайджест должен вычисляться хеш-функцией, лежащей в основе PRF. Любой другой криптонабор, который определяет другую PRF, должен также определять как получают значение «Hash» для вычисления сообщения «Finished». 

В предыдущих версиях TLS значение поля «verify_data» всегда имело длину 12 байт. В текущей версии TLS значение поля зависит от криптонабора. Для любого криптонабора, в котором явно не выражено значение «verify_data_length», оно будет равняться 12. Это правило относится ко всем существующим на настоящий момент (на 2008 год) криптонаборам. Обратите внимание, что это представление данных не отличается от представления в предыдущих версиях. Будущие криптонаборы могут определять и другие значения длины, но она не должна быть меньше 12 байт. 

handshake_messages
Все данные всех сообщений в данном рукопожатии (не включая сообщения «HelloRequest») вплоть до (но не включая) текущее сообщение. Данное сообщение является единственными данными, видимыми на уровне рукопожатия и не включает в себя заголовки уровня записей (см. Разд. 6). По своей природе оно является конкатенацией всех структур рукопожатия (определенных в Разд. 7.4), обмен которыми уже был осуществлен. 

Если в потоке сообщений рукопожатия непосредственно перед сообщением «Finished» не было отправлено/получено сообщение «ChangeCipherSpec» - это считается критической ошибкой.  

Значение «handshake_messages» включает в себя все сообщения рукопожатия как отправленные, так и полученные начиная с клиентского hello-сообщения, и заканчивая, но, не включая, сообщение «Finished». Оно может отличаться от определенного в п. 7.4.8 значения, так как оно может включать в себя сообщение «CertificateVerify» (если оно было отправлено). Также, значение «handshake_messages» для отправленного клиентом сообщения «Finished» будет отличаться от аналогичного значения для отправленного сервером сообщения «Finished», так как отправленное вторым по порядку сообщение будет включать в себя отправленное первым по порядку сообщение «Finished».   

Примечание: сообщения «ChangeCipherSpec», оповещения, а также любые другие типы записей не являются сообщениями рукопожатия и не включаются в расчет дайджеста. Также, в хеш рукопожатия не включается сообщение «HelloRequest». 

8. Криптографические вычисления

Для того, чтобы начать защиту соединения протоколу записи TLS необходима спецификация наборов алгоритмов, основной секрет (master secret), а также случайные значения от клиента и сервера. Схемы аутентификации, шифрования, и алгоритмы построения MAC [35] (кода аутентификации)определяются полем cipher_suite (криптонабор), выбираемым сервером и входящим в состав сообщения «ServerHello». Алгоритм сжатия согласовывается в hello-сообщениях, а случайные значения передаются путем обмена в этих же сообщениях. Все, что остается – это вычислить значение основного секрета.

8.1 Вычисление основного секрета

Для всех методов обмена ключами используется один и тот же алгоритм преобразования предварительного секрета (premaster_secret) в основной секрет (master_secret). Рекомендуется удалить из памяти значение «premaster_secret» сразу же после того как было вычислено значение «master_secret».

«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» в «master_secret» по схеме, описанной выше.

8.1.2 Алгоритм Диффи-Хеллмана

Производится обычное вычисление параметров алгоритма. Согласованный ключ (Z) [36] используется в качестве предварительного ключа, и преобразовывается в основной секрет по схеме, описанной выше. Старшие байты Z, содержащие только нули, отбрасываются перед тем как это число будет использовано в качестве значения «pre_master_secret».

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

9. Обязательные криптонаборы

В отсутствии профильного стандарта приложения, определяющего использование криптонаборов, TLS-совместимое приложение должно поддерживать криптонабор TLS_RSA_WITH_AES_128_CBC_SHA[43] (см. Прил. A.5 для его определения).

10. Протокол данных приложения

Сообщения данных приложения передаются между сторонами уровнем записи, фрагментируются, сжимаются, и зашифровываются согласно текущему рабочему состоянию соединения. Сообщения (в виде фрагментов структуры Plaintext) рассматриваются как неразличимые {англ. transparent} для протокола записи данные [37].

11. Вопросы безопасности

На всем протяжении данной работы описываются некоторые вопросы безопасности. Более глубоко эти темы раскрыты в Прил. D, E и F.  

12. Регистры IANA

В данном документе дается указание на несколько регистров, которые изначально были созданы в стандарте [TLS1.1]. IANA [38] обновила их в целях соответствия данному стандарту. Регистры и их политики присвоения значений (англ. allocation policies) (которые не отличаются от стандарта [TLS1.1]) перечислены ниже:

• TLS ClientCertificateType Identifiers (идентификаторы типа клиентского сертификата): значения в десятичном диапазоне 0-63 с политикой регистрации Standards Action. Значения в десятичном диапазоне 64-223 с политикой регистрации Specification Required. Значения в десятичном диапазоне 224-255 с политикой регистрации Reserved for Private Use [RFC2434][39];

• TLS Cipher Suite (криптонаборы): значения с первым байтом, имеющим значения в десятичном диапазоне 0-191 с политикой регистрации Standards Action. Значения в десятичном диапазоне 192-254 с политикой регистрации Specification Required. Значения в десятичном диапазоне 255 с политикой регистрации Reserved for Private Use [40];
  
  Данный документ определяет несколько криптонаборов с созданием MAC на основе новой схемы HMAC-SHA256, чьи значения (в Прил. A.5) взяты из регистра TLS Cipher Suite;

• TLS ContentType (тип содержимого): значения имеют политику регистрации Standards Action. Диапазон значений – 0-255 в десятичном формате;

• TLS Alerts (оповещения): значения имеют политику регистрации Standards Action. Диапазон значений – 0-255 в десятичном формате.

• TLS HandshakeType (тип рукопожатия): значения имеют политику регистрации Standards Action. Диапазон значений – 0-255 в десятичном формате.

В данном документе также используется регистр, изначально введенный в [RFC4366] [41]. IANA обновила его в целях соответствия данному стандарту. Этот регистр и политики присвоения значений (которые не отличаются от стандарта [RFC4366]) приведен ниже:

• TLS ExtensionType (тип расширений): Диапазон значений – 0-65535 в десятичном формате. IANA обновила данный регистр для того, чтобы включить в него расширение «signature_algorithms» вместе с соответствующим ему значением (см. п. 7.4.1.4). У каждого включенного в регистр расширения имеется флаг Y или N, указывающий на то, рекомендуется данное расширение к использованию в протоколе TLS или нет.

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

• TLS SignatureAlgorithm (алгоритм подписи): первоначальные значения в регистре были указаны в п. 7.4.1.4.1 данного Стандарта. Значения в десятичном диапазоне 0-63 с политикой регистрации Standards Action. Значения в десятичном диапазоне 64-223 с политикой регистрации Specification Required. Значения в десятичном диапазоне 224-255 с политикой регистрации Reserved for Private Use.

• TLS HashAlgorithm (алгоритм хеширования): первоначальные значения в регистре были указаны в п. 7.4.1.4.1 данного Стандарта. Значения в десятичном диапазоне 0-63 с политикой регистрации Standards Action. Значения в десятичном диапазоне 64-223 с политикой регистрации Specification Required. Значения в десятичном диапазоне 224-255 с политикой регистрации Reserved for Private Use.

В данном документе также используется регистр «TLS Compression Method Identifiers» (Идентификаторы метода сжатия). IANA присвоила значение 0 для метода сжатия «null». Значения в десятичном диапазоне 0-63 с политикой регистрации Standards Action. Значения в десятичном диапазоне 64-223 с политикой регистрации Specification Required. Значения в десятичном диапазоне 224-255 с политикой регистрации Reserved for Private Use.

[1] См. п. 7.4.1.3. данного стандарта (часть 3.1 перевода).

[2] PKCS - Public Key Cryptography Standarts (стандарты криптографии с открытым ключом). Пакет спецификаций, разрабатываемый с начала 1990-х годов RSA Laboratories – подразделением компании RSA Security Inc. Некоторые спецификации PKCS определены также в Интернет-стандартах IETF (в виде RFC), а также используются как основа для создания своих стандартов другими организациями (NIST, ISO/IEC, рабочей группой PKIX) (Прим. перев.).

[3] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax Standard", version 1.5, November 1993. Стандарт определен IETF как RFC 2315 - B. Kaliski, "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, Март 1998.

[4] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax Standard", version 1.5, November 1993. – Стандарт определял расширения к старым сертификатам X.509v1, устарел с выходом в 2002 году новой версии основного стандарта ITU-T Recommendation X.509, задававшего формат сертификатов X.509v3. Стандарт включил в себя определение расширений сертификатов (Прим. перев.).

[5] Рекомендация ITU-T X.680 (Abstract Syntax Notation One (ASN.1)) определяет типы данных SET как неупорядоченный список фиксированной длины (англ. fixed, unordered list), содержащий как обязательные, так и необязательные типы данных. Каждое значение типа данных SET является неупорядоченным списком значений, имеющих составной (component) тип данных (см. тж. п. 3.8.72 и Разд. 27 ASN.1) (Прим. перев.).

[6] В отличие от SET ITU-T X.680 определяет типы данных SEQUENCE как упорядоченный список фиксированной длины (англ. fixed, ordered list), содержащий как обязательные, так и необязательные типы. Каждое значение типа данных SEQUENCE является упорядоченным списком значений, имеющих составной тип данных. ASN.1 относит к составным типам данных типы: CHOICE, SET, SEQUENCE, SET OF, а также SEQUENCE OF. В том случае, если составной тип объявлен необязательным, то значения типа SET или SEQUENCE могут не содержать в себе значения, имеющие необязательный тип данных (см. тж. п. 3.8.67 и Разд. 25 ASN.1) (Прим. перев.).

[7] Имеется ввиду, что в PKCS #7 (RFC 2315) (п. 6.6.) тип, определяющий список расширенных сертификатов задается как

ExtendedCertificatesAndCertificates ::=
SET OF ExtendedCertificateOrCertificate.

При этом значение типа SET OF включает в себя неупорядоченный список, содержащий значения одного составного типа (см. тж. п. 3.8.73 и Разд. 28 ASN.1) (Прим. перев.).

[8] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 5081, November 2007. – На данный момент актуален стандарт: Mavrogiannopoulos N., Gillmor D., "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication" RFC 6091, February 2011.

[9] Расширение Key Usage (использование ключа) и расшифровка битовой строки KeyUsage, содержащей области использования ключа и ограничения его использования, содержатся в п. 4.2.1.3 стандарта RFC 5280 « Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ». Также, расширения сертификатов (в том числе Key Usage) определены в разделе 9 стандарта ITU-T Recommendation X.509 | ISO/IEC 9594-8, и Разд. 4.2 RFC 5280 (Прим. перев.).

[10] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.

[11] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006. – На данный момент актуальным является стандарт: Nir, Y., Josefsson, S., Pegourie-Gonnard, M., "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, August 2018. (Прим. перев.).

[12] NIST FIPS 186-4, "Digital Signature Standard", National Institute of Standards and Technology, U.S. Department of Commerce, 2013 (Прим. перев.).

[13] Eastlake 3rd, D., RFC6066, «Transport Layer Security (TLS) Extensions: Extension Definitions», January 2011.

[14] При использовании алгоритма Диффи-Хеллмана (DH) его параметры могут быть как постоянными (англ. fixed), так и кратковременными (тж. эфемерными) (англ. ephemeral). Кратковременные параметры могут создаваться при каждом новом соединении, в то время как постоянные параметры могут храниться на жестком диске. Соответственно, алгоритм c кратковременными параметрами обозначается добавлением дополнительной литеры «E» - DHE, ECDHE в отличие от алгоритма с постоянными параметрами – DH, ECDH (Прим. перев.).

[15] В стандарте TLS 1.0 (RFC 2246, п. 7.4.2) метод обмена ключами DH_DSS описан как: ключ - DH. Алгоритм подписи сертификата - DSS.
Метод обмена ключами DH_RSA описан как: ключ - DH. Алгоритм подписи сертификата - RSA.

В стандарте RFC 4492 «Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)» метод обмена ключами ECDH_ECDSA (Разд. 2.1)
описан как: публичный ключ – ECDH подписанный ECDSA.
Метод обмена ключами ECDH_RSA (Разд. 2.3) описан как: публичный ключ – ECDH подписанный RSA (Прим. перев.).

[16] Поле SubjectPublicKeyInfo является одним из полей упорядоченного списка TBSCertificate, который, в свою очередь, является одним из трех полей упорядоченного списка Certificate, что является базовым синтаксисом сертификатов стандарта X.509v3.

Подробнее о синтаксисе см. Разд. 4.2 стандарта RFC 5280 « Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile».

Содержимое поля SubjectPublicKeyInfo определено в стандарте RFC 3279 «Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» (Прим. перев.).

[17] OID (Оbject identifier) – идентификатор объекта. Строка или последовательность десятичных цифр, однозначно идентифицирующая объект. Такими объектами обычно являются классы объектов или атрибуты.

Структура OID представляет собой так называемые деревья (древовидные структуры), в которой от каждого объекта можно протянуть цепочку до регистрирующего органа, находящегося на вершине структуры. Таким образом - id-RSASSA-PSS является строковым значением (тж. именем) объекта (в данном случае объект обозначает алгоритм подписи), которому соответствует последовательность 1.2.840.113549.1.1.10. Каждому значению числовой последовательности должно быть сопоставлено свое имя, поэтому приведенная последовательность может быть также представлена как: {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsassa-pss(10)} (в формате ASN.1) или /ISO/Member-Body/US/113549/1/1/10 (в формате IRI).

Формат OID определен в рекомендациях ITU-T X.660 | ISO/IEC 9834-1 "Procedures for the operation of object identifier registration authorities: General procedures and top arcs of the international object identifier tree".

Условия для использования схемы RSASSA-PSS приведены в Разд. 3 RFC 4055 «Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure» (Прим. перев.).

[18] Если число g является первообразным корнем по модулю p, это означает, что:
каждое взаимно простое с p число (например, m) будет сравнимо по модулю p со степенью числа g (то есть, для каждого числа m будет существовать какое-либо целое положительное число k такое, что m ≡ g^k (mod p)) (Прим. перев.).

[19] 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", NIST, 2013" (Прим. перев.).

[20] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. – На данный момент стандарт устарел, актуальная версия: D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. В основе этого стандарта лежит более фундаментальный стандарт ITU-T Recommendation X.509 | ISO/IEC 9594-8, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks". (Прим. перев.).

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

[22] ITU-T Recommendation X.501: Information Technology – Open Systems Interconnection - The Directory: Models, 1993.
Последняя версия стандарта: ITU-T X.501: Information technology – Open Systems Interconnection – The Directory: Models, 10/2019.

[23] Термин «выделенное имя» дается по официальному переводу стандарта X.501 версии 2005 года на русский язык (других переводов на русский язык не имеется), чтобы избежать разночтений и разногласий. Сам перевод, приведен на сайте itu.int: МСЭ-Т X.501: Информационные технологии – Взаимосвязь открытых систем – Справочник: Модели, 08/2005.

Под выделенным именем понимается вся цепочка доверия, начиная от рассматриваемого сертификата и заканчивая корневым удостоверяющим центром. Выделенное имя является последовательностью относительных выделенных имен (англ. relative distinguished name, RDN), где под RDN подразумеваются атрибуты конкретного сертификата без цепочки доверия, проведенной до корневого центра сертификации (Прим. перев.).

[24] 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).
На данный момент вышла новая версия стандарта, датированная февралем 2021 года.

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

[25] Соответственно, поле «client_version» имеет размер 2 байта. См. тж. п. 7.4.1.2 и Прил. E данного стандарта (Прим. перев.).

[26] Bleichenbacher D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1" in Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1-12, 1998.

[27] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, March 2003.

[28] На данный момент актуальная версия стандарта существует в виде RFC 8017 - Moriarty, K., (ред.), Kaliski, B., Jonsson, J., Rusch, A., "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, ноябрь 2016 (Прим. перев.).

[29] В данном контексте, также как и в работе [KPR03] символ «||» означает конкатенацию (Прим. перев.).

[30] Схема также описывается в стандарте RFC 8017 и в его устаревшей версии – RFC 3447 (п. 7.2 в обоих стандартах). См. тж. предыдущий комментарий (Прим. перев.).

[31] PDU (Protocol Data Unit), БДП (блок данных протокола) - единичный блок данных, передаваемых тем или иным протоколом между узлами компьютерной сети. Для протокола TCP таким БДП будет пакет данных, для UDP – датаграмма и т. д. (Прим. перев.).

[32] RSA-blinding – процесс дешифрования шифротекста с использованием случайно сгенерированного перед этой операцией параметра r. Если g – это шифротекст, который надо расшифровать, p и q – два случайно выбранных простых числа, e – показатель степени (экспонента) шифрования, при этом число N = pq. Перед каждой операцией дешифровки высчитывается значение x = (r^e)g mod N. После чего производится обычная расшифровка значения x, после которой следует деление полученного результата на r, например: (x^e)/r mod N. Поскольку r и x являются случайными значениями, то время на расшифровку значений ничего не скажет о размере закрытого ключа. Естественно, такие дополнительные операции выразятся в некоторой потере производительности (Прим. перев.).

[33] Boneh, D., Brumley, D., "Remote timing attacks are practical", USENIX Security Symposium 2003.

[34] Вычисляется клиентом по аналогии с открытым числом сервера, произвольно выбирая целое положительное число Y и найдя остаток от деления g^Y на p (dh_Yс = g^Y mod p). О числах p и g см. подробнее Разд. 7.4.3 данного Стандарта (Прим. перев.).

[35] Код аутентификации сообщения, (англ. message authentiation code). Также в некоторых русскоязычных источниках может употребляться термин «имитовсктавка» (Прим. перев.).

[36] В алгоритме Диффи-Хеллмана согласованное значение ключа вычисляется обеими сторонами с использованием закрытых и открытых ключей. Клиент получает открытое значение (ключ) сервера dh_Ys (см. п. 7.4.3), а сервер получает открытый ключ клиента (см. п. 7.4.7.2). В результате вычисления обе стороны общий получают согласованный ключ Z = dh_Ys ^ с mod p = dh_Yc ^ s mod p = g ^ ab mod p. Где c и s – закрытые ключи клиента и сервера, соответственно (определение g, p см. в п. 7.4.3) (Прим. перев.).

[37] См. тж. Разд. 6.2 данной спецификации.

[38] IANA - Internet Assigned Numbers Authority. Организация, занимающаяся управлением пространствами IP-адресов, доменов верхнего уровня, а также регистрирующая типы данных MIME и параметры прочих протоколов Интернета (в том числе и параметры протокола TLS) (Прим. перев).

[39] Narten, T., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, октябрь 1998. – На настоящий момент актуальным стандартом является: Cotton, M., Leiba, B., Narten, T., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, июнь 2017.

Все указанные политики приводятся в данных стандартах. В настоящее время все политики регистрации параметров разделены на 10 категорий, где 10 категория – категория с самыми строгими требованиями к регистрации. Соответственно, категория 1 – с самыми простыми требованиями к регистрации (заявительный порядок регистрации).

Политика Standards Action имеет 9 категорию, Specification Required – 6 категорию, Reserved for Private Use – 1 категорию (см. тж. Разд. 4 RFC 8126) (Прим. перев.).

[40] В настоящее время зарегистрированные криптонаборы данного регистра имеют кодовые значения в виде двух байтов в 16-ричном формате, начиная от 0x00, 0x00 и заканчивая 0xFF, 0xFF (от 0x0, 0x0 до 0x255, 0x255 – в десятичном формате). При этом сам регистр не указывает к какой политике - Standards Action или Specification Required принадлежит тот или иной криптонабор. Вместо этого у каждого криптонабора имеется флаг Y или N, указывающий на то, рекомендуется данный криптонабор к использованию в протоколе TLS или нет. При этом, если криптонабор не рекомендуется к использованию – это еще не означает, что в нем есть какие-то недостатки. Это может значить, что в IETF еще не пришли к консенсусу по поводу его использования, либо он имеет ограниченное использование, либо предназначен только для специфических задач.

Диапазон 0xFE,0xFE-FF зарезервирован для того, чтобы избежать конфликтов с широко распространенными реализациями.

Диапазон 0xFF,0x00-FF зарезервирован для политики Private Use. (Прим. перев.).

[41] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., Wright, T., "Transport Layer Security (TLS) Extensions", RFC 4366, апрель 2006. – На настоящий момент актуальным стандартом является: Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, январь 2011.

[42] Определение структуры "CertificateRequest" дается согласно ошибки ID 2865 с подтвержденным статусом из раздела "Ошибки" (Errata) для RFC 5246. Исходный текст стандарта, который приведен на официальной странице спецификации, задает в вектор переменной длины supported_signature_algorithms как supported_signature_algorithms<2^16-1>. При этом не задаются нижнее и верхнее значение массива, и не учитывается то, что его длина должна быть числом, кратным базовому типу SignatureAndHashAlgorithm (2 байта, в данном случае). Правильное определение данного поля приведено в п. 7.4.1.4.1 Стандарта (Прим. перев.).

[43] Ошибка ID 6572 с неподтвержденным статусом из раздела "Ошибки" (Errata) для RFC 5246 говорит, что обязательным для поддержки криптонабором должен быть определенный в Прил. 5 криптонабор TLS_RSA_WITH_AES_128_GCM_SHA256, а не TLS_RSA_WITH_AES_128_CBC_SHA. Это объясняется тем, что шифр AES_128_CBC подвержен уязвимости атаки на основе открытого текста (англ. plain-text attack), а хеш-функция SHA не является достаточно надежной (Прим. перев.).