SSL-как общие имена (CN) и альтернативные имена субъектов (SAN) работают вместе? | Блог о программировании

Что в tls 1.3?

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

• Плохие шифры удалены, остались только хорошие. Инициализировать сессию TLS 1.3 на плохих шифрах не получится. Всё дело в новых cipher suites: тут и другие алгоритмы обмена сеансовых ключей, и так называемый HMAC – не будем углубляться в подробности, потому что Патрик устал. Вкратце: раньше подпись каждого TLS-пакета шла отдельно. На это были атаки, потому что было известно, какой там контент находится. Сейчас ее запихали вовнутрь (режим AEAD), и в TLS 1.3 по-другому быть не может, соответственно, мы избавились от таких атак.
• Handshake стал короче – нет старых сообщений, нет старых расширений, нет возможности по каким-то странным штукам обменяться ключиками. То есть, он тупо короче количественно – даже самый полный TLS 1.3 handshake короче, чем в TLS 1.2.
• Переход на шифрованный канал происходит почти что сразу. Для этого используются разные ключики: да, пока не договорились о хороших ключиках, оптимальных, мы используем какие попало, но канал уже шифрованный. То есть hello – hello и пошло всё зашифрованное. Из-за этого сложнее всё это ломать.
• Всё регламентировано, больше не надо пытаться менять размеры пакетов, забивая их ноликами, чтобы сложнее было расшифровывать.
• Своя пара ключей на каждую сеансовую фазу. Сеансовые ключи меняются: пока мы ни о чем не договорились – они такие, договорились о более крутых – они более крутые, сертификаты проверили и всё хорошо – еще другие ключи. В итоге их много, они усложняются и очень трудно это всё поломать. Еще одна важная вещь, почему это быстрее: Early Data (она же 0-RTT, Zero Round Trip Time) – это когда у тебя в TLS-handshake посылается полезная инфа – ну например GET-запрос. То есть нет такого, что поговорили-поговорили и только потом посылаем что-то отдельным потоком. Сразу же в handshake идет запрос. Как только сервер его получил, он начинает его обрабатывать, отдает клиенту свои данные, сертификат и пока клиент проверяет, сервер уже готов отдать. И может даже в TLS-handshake и отдать иногда.
• Есть pre-shared key, то есть клиент с сервером могут договориться и сохранить сеансовые ключи для последующих соединений. И, соответственно, когда происходит handshake таких вот договорившихся клиентов, на этап выбора ключей время не тратится. Долго объяснять, как это сделано криптографически, но тех атак, которые были на Session ID, вот в этом месте сейчас нет (что хорошо). Всё стало безопаснее и быстрее.

Основная проблема, что поддержка TLS 1.3 – она во всех браузерах, которые актуальны, есть, но не во всех по дефолту включена. Например, в Safari нет (но там очень легко включить), Google Chrome и Mozilla Firefox уже по дефолту поддерживают TLS 1.3. Ngnix с TLS 1.3 – без проблем, в Apache есть нюансы, а вот с почтовыми клиентами хуже — там только Exim молодец, а остальные не очень.

В общем, это наше будущее, там всё получше и попроще, самое главное. Но пока оно еще не везде наступило.

Basic constraints

Еще одна штука, которая улучшает секьюрити (и с этим были серьезные баги до 2003 года в Internet Explorer): в промежуточных сертификатах в поле Basic Constraints должно быть написано

CA: true

, что означает, что этим сертификатам разрешено подписывать конечные сертификаты. Если этой штуки нет, то клиент при проверке цепочки должен сказать: «я не могу принять этот промежуточный сертификат» – несмотря на то, что все подписи совпадают, в субъекте всё совпадает и т.д.

Еще раз, если кто не понял: если эту штуку не проверять, я могу получить сертификат от Let’s Encrypt и потом этим сертификатом подписывать что угодно. И цепочка будет валидная.

Capi и scvp

Еще про верификацию и про цепочку. Есть маленькая особенность – похвалим здесь Windows. Если сервер не отдал сертификат, в обычном (традиционном) подходе сертификат нам взять неоткуда, цепочки нет, всё сломалось. Так вот, в Windows есть такая штука как Certificate API, и она может достроить цепочку, взяв промежуточные сертификаты из своего хранилища.

Как эти сертификаты туда попадают? Либо залиты в хранилище, либо из сертификата, установленного на сервере. Например, в Plesk, если получить сертификат от Comodo и поставить его на домен – в хранилище попадет промежуточный сертификат от Comodo.

Ну и еще люди, которым Windows нравится, придумали SCVP (Server-based Certificate Validation Protocol). В действительности не работает почти ни у кого и нигде – в смысле глобально и массово, — но как концепция есть. Более того, есть продукты, которые это делают, и даже в каких-то сетях это может быть настроено.

Это сервис, который за тебя эту цепочку строит и частично даже проверяет, что удобно. Если там заявлена поддержка DPV (Delegated Path Validation), то он цепочку еще и провалидирует. То есть, клиенту надо этому сервису отправить сертификат и получить ответ – продолжать сессию или рвать.

Предположительно это могло бы всё ускорить, но из-за того, что сервису тоже надо как-то доверять, идея глохнет. И всё-таки она была.

Итак, вот у нас получается такая вот цепочка.

Прежде всего мы проверяем, что с подписями у нас всё нормально: выстраиваем цепочку, проверяем подписи – и считаем, что содержимое сертификатов верно. Дальше нам надо проверить конечный сертификат. Промежуточный нам проверять не надо, потому что мы идем к Патрику и проверить нам надо только самый последний сертификат.

Давайте проверять.

Certificate verification: chain

Возможно, вы обратили внимание на формулировку: посылается не сертификат, а

сертификаты

– сейчас станет понятно, почему (в общем-то, догадаться нетрудно).

Сертификат подписывается ишьюером – тем человеком, который этот сертификат выписал. Для того, чтобы считать этот сертификат правильным и все данные в нем верными, мы должны доверять этому ишьюеру – то есть верить, что он всякую фигню не подписывает. Чтобы вся эта система работала, придумали такую концепцию как корневой сертификат (root certificate).

I. общие положения

1. Настоящие Требования разработаны в соответствии с Федеральным законом от 6 апреля 2021 г. № 63-ФЗ «Об электронной подписи» (далее – Федеральный закон).

2. В настоящих Требованиях используются следующие основные понятия, определенные в статье 2 Федерального закона:

1) электронная подпись (далее – ЭП) – информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию;

2) ключ ЭП – уникальная последовательность символов, предназначенная для создания ЭП;

3) ключ проверки ЭП – уникальная последовательность символов, однозначно связанная с ключом ЭП и предназначенная для проверки подлинности ЭП (далее – проверка ЭП);

4) удостоверяющий центр (далее – УЦ) – юридическое лицо или индивидуальный предприниматель, осуществляющие функции по созданию и выдаче сертификатов ключей проверки ЭП, а также иные функции, предусмотренные Федеральным законом;

5) сертификат ключа проверки ЭП – электронный документ или документ на бумажном носителе, выданные УЦ либо доверенным лицом УЦ и подтверждающие принадлежность ключа проверки ЭП владельцу сертификата ключа проверки ЭП;

6) квалифицированный сертификат ключа проверки ЭП (далее – квалифицированный сертификат) – сертификат ключа проверки ЭП, выданный аккредитованным УЦ или доверенным лицом аккредитованного УЦ либо федеральным органом исполнительной власти, уполномоченным в сфере использования ЭП (далее – уполномоченный федеральный орган);

7) владелец сертификата ключа проверки ЭП – лицо, которому в установленном Федеральным законом порядке выдан сертификат ключа проверки ЭП;

8) аккредитация УЦ – признание уполномоченным федеральным органом соответствия УЦ требованиям Федерального закона;

9) средства ЭП – шифровальные (криптографические) средства, используемые для реализации хотя бы одной из следующих функций – создание ЭП, проверка ЭП, создание ключа ЭП и ключа проверки ЭП;

10) средства УЦ – программные и (или) аппаратные средства, используемые для реализации функций УЦ;

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

3. Настоящие Требования устанавливают требования к совокупности и порядку расположения полей квалифицированного сертификата (далее – форма квалифицированного сертификата).

4. При включении в состав квалифицированного сертификата дополнительных полей требования к их назначению и расположению в квалифицированном сертификате определяются в техническом задании на разработку (модернизацию) средств УЦ.

Ii. требования к совокупности полей квалифицированного сертификата

5. Требования к совокупности полей квалифицированного сертификата устанавливаются на основании Федерального закона.

6. В соответствии со статьями 14 и 17 Федерального закона квалифицированный сертификат должен содержать следующую информацию:

– уникальный номер квалифицированного сертификата;

– даты начала и окончания действия квалифицированного сертификата;

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

– страховой номер индивидуального лицевого счета (далее – СНИЛС) владельца квалифицированного сертификата – для физического лица;

– основной государственный регистрационный номер (далее – ОГРН) владельца квалифицированного сертификата – для юридического лица;

– идентификационный номер налогоплательщика (далее – ИНН) владельца квалифицированного сертификата – для юридического лица;

– ключ проверки ЭП;

– наименование используемого средства ЭП и (или) стандарты, требованиям которых соответствует ключ ЭП и ключ проверки ЭП;

– наименования средств ЭП и средств аккредитованного УЦ, которые использованы для создания ключа ЭП, ключа проверки ЭП, квалифицированного сертификата, а также реквизиты документа, подтверждающего соответствие указанных средств требованиям, установленным в соответствии с Федеральным законом;

– наименование и место нахождения аккредитованного УЦ, который выдал квалифицированный сертификат;

– номер квалифицированного сертификата аккредитованного УЦ;

– ограничения использования квалифицированного сертификата (если такие ограничения установлены).

7. Квалифицированный сертификат должен содержать квалифицированную ЭП аккредитованного УЦ (доверенного лица аккредитованного УЦ, уполномоченного федерального органа), подтверждающую принадлежность ключа проверки ЭП владельцу квалифицированного сертификата.

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

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

Iii. требования к порядку расположенияполей квалифицированного сертификата

9. Требования к порядку расположения полей квалифицированного сертификата устанавливаются в соответствии с основами аутентификации в открытых системах*(1), структурой сертификата открытого ключа и сертификата атрибутов*(2) и профилем сертификата и списка аннулированных сертификатов*(3).

10. Структура квалифицированного сертификата в форме электронного документа, определенная в соответствии со спецификацией абстрактной синтаксической нотации версии один*(4), должна иметь следующий общий вид:

Certificate ::= SIGNED { SEQUENCE {

    version                 [0]     Version DEFAULT v l,

    serialNumber                    CertificateSerialNumber,

    signature                       AlgorithmIdentifier,

    issuer                          Name,

    validity                        Validity,

    subject                         Name,

    subjectPublicKeyInfo            SubjectPublicKeyInfo,

    issuerUniqueIdentifier  [1]     IMPLICIT UniqueIdentifier OPTIONAL,

    subjectUniqueIdentifier [2]     IMPLICIT UniqueIdentifier OPTIONAL,

    extensions              [3]     Extensions OPTIONAL } }

SIGNED { ToBeSigned } ::= SEQUENCE {

    toBeSigned                      ToBeSigned,

    COMPONENTS OF                   SIGNATURE { ToBeSigned } }

SIGNATURE { ToBeSigned } ::= SEQUENCE {

    algorithmIdentifier             AlgorithmIdentifier,

    encrypted                       ENCRYPTED-HASH { ToBeSigned } }

ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING (CONSTRAINED BY

                                       { ToBeSigned }).

11. Поле algorithmIdentifier (идентификатор алгоритма) содержит идентификатор криптографического алгоритма, с использованием которого аккредитованный УЦ, доверенное лицо аккредитованного УЦ либо уполномоченный федеральный орган сформировал ЭП настоящего квалифицированного сертификата. Дополнительно могут быть указаны параметры криптографического алгоритма:

AlgorithmIdentifier ::= SEQUENCE {

    algorithm   ALGORITHM.&id ({ SupportedAlgorithms }),

    parameters  ALGORITHM.&Type ({ SupportedAlgorithms }

                                    {@algorithm }) OPTIONAL }.

12. Поле encrypted содержит ЭП, сформированную аккредитованным УЦ, доверенным лицом аккредитованного УЦ либо уполномоченным федеральным органом под структурированной совокупностью полей квалифицированного сертификата (toBeSigned).

13. Поле version (версия) содержит номер версии формата сертификата: Version ::= INTEGER { vl(0), v2(1), v3(2) }.

Ввиду необходимости использования дополнений сертификата значение поля version должно равняться 2.

14. Поле serialNumber (серийный номер) должно содержать положительное целое число, однозначно идентифицирующее квалифицированный сертификат в множестве всех сертификатов, выданных данным аккредитованным УЦ, доверенным лицом аккредитованного УЦ либо уполномоченным федеральным органом: CertificateSerialNumber ::= INTEGER.

15. Поле signature (подпись) содержит идентификатор криптографического алгоритма, с использованием которого аккредитованный УЦ, доверенное лицо аккредитованного УЦ либо уполномоченный федеральный орган сформировали ЭП данного квалифицированного сертификата. Содержимое данного поля должно совпадать с содержимым поля algorithmIdentifier.

16. Поле issuer (издатель) имеет тип Name и идентифицирует аккредитованный УЦ, доверенное лицо аккредитованного УЦ либо уполномоченный федеральный орган, создавшие и выдавшие данный квалифицированный сертификат. Тип Name описывается следующим образом:

Name ::= CHOICE { rdnSequence RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {

    type     AttributeType,

    value    Attribute Value }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY DEFINED BY AttributeType.

Тип поля value определяется типом атрибута, но в общем случае в качестве AttributeValue выступает тип DirectoryString:

DirectoryString ::= CHOICE {

    teletexString          TeletexString (SIZE (1 ..MAX)),

    printableString        PrintableString (SIZE (1 ..MAX)),

    universalString        UniversalString (SIZE (1. .MAX)),

    utf8String             UTF8String (SIZE (1 ..MAX)),

    bmpString              BMPString (SIZE (1..MAX))}.

17. Стандартные атрибуты имени описаны в справочнике выбранных типов атрибутов*(5). При описании формы квалифицированного сертификата используются следующие стандартные атрибуты имени:

1) commonName (общее имя).

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

2) surname (фамилия).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую фамилию физического лица. Объектный идентификатор типа атрибута surname имеет вид 2.5.4.4;

3) givenName (приобретенное имя).

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

4) countryName (наименование страны).

В качестве значения данного атрибута имени следует использовать двухсимвольный код страны*(6). Объектный идентификатор типа атрибута countryName имеет вид 2.5.4.6;

5) stateOrProvinceName (наименование штата или области).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;

6) localityName (наименование населенного пункта).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего населенного пункта. Объектный идентификатор типа атрибута localityName имеет вид 2.5.4.7;

7) streetAddress (название улицы, номер дома).

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

8) organizationName (наименование организации).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование юридического лица. Объектный идентификатор типа атрибута organizationName имеет вид 2.5.4.10;

9) organizationUnitName (подразделение организации).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование подразделения юридического лица. Объектный идентификатор типа атрибута organizationUnitName имеет вид 2.5.4.11;

10) title (должность).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование должности лица. Объектный идентификатор типа атрибута title имеет вид 2.5.4.12.

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

18. К дополнительным атрибутам имени, необходимость использования которых устанавливается в соответствии с Федеральным законом, относятся:

1) OGRN (ОГРН).

Значением атрибута OGRN является строка, состоящая из 13 цифр и представляющая ОГРН владельца квалифицированного сертификата – юридического лица. Объектный идентификатор типа атрибута OGRN имеет вид 1.2.643.100.1, тип атрибута OGRN описывается следующим образом:

OGRN ::= NUMERIC STRING SIZE 13;

2) SNILS (СНИЛС).

Значением атрибута SNILS является строка, состоящая из 11 цифр и представляющая СНИЛС владельца квалифицированного сертификата – физического лица. Объектный идентификатор типа атрибута SNILS имеет вид 1.2.643.100.3, тип атрибута SNILS описывается следующим образом:

SNILS ::= NUMERIC STRING SIZE 11;

3) INN (ИНН).

Значением атрибута INN является строка, состоящая из 12 цифр и представляющая ИНН владельца квалифицированного сертификата. Объектный идентификатор типа атрибута INN имеет вид 1.2.643.3.131.1.1, тип атрибута INN описывается следующим образом:

INN ::= NUMERIC STRING SIZE 12.

19. Поле validity имеет тип Validity и содержит даты начала и окончания действия квалифицированного сертификата. Тип Validity описывается следующим образом:

Validity:-SEQUENCE}

    notBefore        Time,

    notAfter         Time}

Time ::= CHOICE {

    utcTime          UTCTime,

    generalTimeGeneralizedTime}.

20. Поле subject имеет тип Name и идентифицирует владельца квалифицированного сертификата.

21. Поле subjectPublicKeylnfo имеет тип SubjectPublicKeylnfo и содержит значение ключа проверки ЭП владельца квалифицированного сертификата, а также идентификатор криптографического алгоритма, с которым должен использоваться данный ключ:

SubjectPublicKeyInfo ::= SEQUENCE {

    algorithm               AlgorithmIdentifier,

    subjectPublicKey        BIT STRING }.

22. Необязательные поля issuerUniqueIdentifier и subjectUniqueIdentifier имеют тип UniqueIdentifier. Настоящие Требования не устанавливают требований к использованию указанных полей.

23. Дополнительная информация, касающаяся использования квалифицированного сертификата, включается в состав дополнений:

Extensions ::= SEQUENCE {

    extnId      EXTENSION.&id ({ ExtensionSet}),

    critical    BOOLEAN DEFAULT FALSE,

    extnValue   OCTET STRING }.

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

24. Дополнение authority Key Identifier (идентификатор ключа УЦ) имеет тип Authority KeyIdentifier, структура которого определяется следующим образом:

AuthorityKeyIdentifier ::= SEQUENCE {

    keyIdentifier             [0] KeyIdentifier    OPTIONAL,

    authorityCertIssuer       [1] GeneralNames     OPTIONAL,

    authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL}.

В квалифицированном сертификате следует использовать дополнение authorityKeyIdentifier с занесением в поле authorityCertSerialNumber номера соответствующего квалифицированного сертификата аккредитованного УЦ или доверенного лица аккредитованного УЦ либо уполномоченного федерального органа, создавшего исходный квалифицированный сертификат. Объектный идентификатор типа дополнения authorityKeyIdentifier имеет вид 2.5.29.35.

25. Дополнение keyUsage определяет область использования ключа проверки ЭП, содержащегося в поле subjectPublicKeylnfo квалифицированного сертификата. Дополнение keyUsage имеет тип KeyUsage, структура которого определяется следующим образом:

KeyUsage ::= BIT STRING {

    digitalSignature      (0),

    contentCommitment     (1),

    keyEncipherment       (2),

    dataEncipherment      (3),

    keyAgreement          (4),

    keyCertSign           (5),

    cRLSign               (6),

    encipherOnly          (7),

    decipherOnly         (8)}.

Значение «1» в нулевом бите означает, что область использования ключа включает проверку ЭП под электронными документами, отличными от квалифицированных сертификатов и списков уникальных номеров квалифицированных сертификатов ключей проверки ЭП, действие которых на определенный момент было прекращено УЦ до истечения их действия (далее – список аннулированных сертификатов), предназначенными для выполнения процедур аутентификации или контроля целостности.

Значение «1» в первом бите означает, что область использования ключа включает проверку ЭП под электронными документами, отличными от квалифицированных сертификатов и списков аннулированных сертификатов, в отношении которых ставится задача обеспечения невозможности отказа подписавшего лица от своего действия.

Значение «1» во втором бите означает, что область использования ключа включает зашифрование закрытых или секретных ключей, например в целях их защищенной доставки.

Значение «1» в третьем бите означает, что область использования ключа включает непосредственно зашифрование пользовательских данных без дополнительного использования методов симметричной криптографии.

Значение «1» в четвертом бите означает, что область использования ключа включает согласование ключей.

Значение «1» в пятом бите означает, что область использования ключа включает проверку подписей под квалифицированными сертификатами.

Значение «1» в шестом бите означает, что область использования ключа включает проверку подписей под списками аннулированных сертификатов.

Значение «1» в седьмом бите означает, что область использования ключа включает зашифрование данных в процессе согласования ключей (при этом в четвертом бите должно быть значение «1»).

Значение «1» в восьмом бите означает, что область использования ключа включает расшифрование данных в процессе согласования ключей (при этом в четвертом бите должно быть значение «1»).

Объектный идентификатор дополнения keyUsage имеет вид 2.5.29.15.

26. Дополнение certificatePolicies предназначено для обозначения политик сертификации, в соответствии с которыми должен использоваться квалифицированный сертификат. Тип CertificatePoliciesSyntax, описывающий дополнение certificatePolicies, определяется следующим образом:

CertificatePoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF Policylnformation

Policylnformation ::= SEQUENCE {

    policyIdentifier        CertPolicyId,

    policyQualifiers        SEQUENCE SIZE (1 ..MAX) OF

                            PolicyQualifierInfo OPTIONAL}

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {

    policyQualifierId       PolicyQualifierId,

    qualifier               ANY DEFINED BY policyQualifierId }

PolicyQualifierId ::= OBJECT IDENTIFIER.

Объектный идентификатор дополнения certificatePolicies имеет вид 2.5.29.32.

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

– 1.2.643.100.113.1 – класс средства ЭП КС 1,

– 1.2.643.100.113.2 – класс средства ЭП КС2,

– 1.2.643.100.113.3 – класс средства ЭП КС3,

– 1.2.643.100.113.4 – класс средства ЭП КВ1,

– 1.2.643.100.113.5 – класс средства ЭП КВ2,

– 1.2.643.100.113.6 – класс средства ЭП КА1.

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

– для класса средств ЭП КС 1: 1.2.643.100.113.1,

– для класса средств ЭП КС2: 1.2.643.100.113.1, 1.2.643.100.113.2,

– для класса средств ЭП КС3: 1.2.643.100.113.1, 1.2.643.100.113.2, 1.2.643.100.113.3,

– для класса средств ЭП КВ1: 1.2.643.100.113.1, 1.2.643.100.113.2, 1.2.643.100.113.3, 1.2.643.100.113.4,

– для класса средств ЭП КВ2: 1.2.643.100.113.1, 1.2.643.100.113.2, 1.2.643.100.113.3, 1.2.643.100.113.4, 1.2.643.100.113.5,

– для класса средств ЭП КА1: 1.2.643.100.113.1, 1.2.643.100.113.2, 1.2.643.100.113.3, 1.2.643.100.113.4, 1.2.643.100.113.5, 1.2.643.100.113.6.

Для средств ЭП, класс которых отличается от класса средств УЦ, в которых используются указанные средства ЭП, следует указывать идентификаторы для класса средств ЭП, соответствующего классу средств УЦ.

29. Для указания в квалифицированном сертификате наименования используемого владельцем квалифицированного сертификата средства ЭП должно использоваться некритичное дополнение subjectSignTool типа UTF8String SIZE(1..200), объектный идентификатор которого имеет вид 1.2.643.100.111.

30. Для указания в квалифицированном сертификате наименования средств ЭП и средств аккредитованного УЦ, которые использованы для создания ключа ЭП, ключа проверки ЭП, квалифицированного сертификата, а также реквизитов документа, подтверждающего соответствие указанных средств требованиям, установленным законодательством Российской Федерации, должно использоваться некритичное дополнение issuerSignTool типа IssuerSignTool, имеющего следующее представление:

IssuerSignTool ::= SEQUENCE {

    signTool            UTF8String SIZE(1.200),

    cATool              UTF8String SIZE(1..200),

    signToolCert        UTF8String SIZE(1.. 100),

    cAToolCert          UTF8String SIZE(1.100) }.

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

В строковом поле cATool должно содержаться полное наименование средства аккредитованного УЦ, которое было использовано для создания ключа ЭП, ключа проверки ЭП и квалифицированного сертификата.

В строковом поле signToolCert должны содержаться реквизиты заключения ФСБ России о подтверждении соответствия средства ЭП, которое было использовано для создания ключа ЭП, ключа проверки ЭП, требованиям, установленным в соответствии с Федеральным законом (далее – заключение о подтверждении соответствия средства электронной подписи).

В строковом поле cAToolCert должны содержаться реквизиты заключения ФСБ России о подтверждении соответствия средства УЦ, которое было использовано для создания квалифицированного сертификата, требованиям, установленным в соответствии с Федеральным законом (далее – заключение о подтверждении соответствия средства удостоверяющего центра).

Объектный идентификатор типа IssuerSignTool имеет вид 1.2.643.100.112.

Intermediate certificate

Следующий в цепочке – Intermediate Certificate. Зачем он нужен? Дело в том, что в случае, если с Root CA Certificate что-то пошло не так, очень сложно его поменять. Центру сертификации нужно сделать новый приватный ключ, новый публичный ключ, всем это всё нужно обновить и так далее, это утомительно и это ломает всю секьюрити.

И вообще, чем меньше мы работаем с машиной, на которой находится этот CA, тем меньше шансов, что этот приватный ключ украдут. Поэтому CA выписывают промежуточные сертификаты и уже с их помощью подписывают конечные (end-entity) сертификаты для вашего домена.

Такая цепочка происходит очень часто и сертификат для нашего Патрика может быть подписан Губкой Бобом, а сертификат Губки Боба – Мистером Крабсом (а Губка Боб работает на мистера Крабса, как мы знаем из мультика). То есть это, в принципе, может быть вообще одна организация.

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

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

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

Поэтому если вы видите сертификат, в котором этих полей нет, можно возбудиться и что-нибудь покопать – возможно, там всё не очень хорошо.

Iv. требования к форме квалифицированного сертификатана бумажном носителе

31. Форма квалифицированного сертификата на бумажном носителе должна удовлетворять следующим требованиям:

– отображение всех полей квалифицированного сертификата в виде, пригодном для восприятия человеком;

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

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

Допускается не отображать в квалифицированном сертификате на бумажном носителе значения полей, которые фиксированы для всех квалифицированных сертификатов (например: поле version имеет значение 2, соответствующее версии v3).

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

32. Общий вид квалифицированного сертификата на бумажном носителе для владельца – физического лица приведен в приложении № 1 к настоящим Требованиям.

Общий вид квалифицированного сертификата на бумажном носителе для владельца – юридического лица приведен в приложении № 2 к настоящим Требованиям.

_____________________________

*(1) Справочно: Основы аутентификации в открытых системах определены в ГОСТ Р ИСО/МЭК 9594-8-98 «Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации».

Ocsp stapling

Это примерно в ту же степь, но тут мы уже начинаем уходить от структуры Certificate Authority. То есть возлагаем эту проверку на сервер. Как это работает: сервер периодически ходит по этому OSCP URL-у и говорит: «OCSP-resolver, посмотри-ка, вот этот мой сертификат – в отозванных или нет?».

OCSP-resolver отвечает подписанным ответом, наш сервер его запоминает, и когда клиент приходит, ему отдаётся этот ответ. То есть у клиента есть подписанный ответ и в нём написано, что всё хорошо. Из-за того, что серверов меньше, чем клиентов и сервер может на какое-то время это кэшировать, нагрузка на всех становится меньше.

Тут есть тоже некоторые проблемы: текущий механизм — это только на один сертификат, а у нас цепочка (и это важно). А еще, из-за того, что мой сервер отвечать на это не обязан, клиент не может рассчитывать на то, что OSCP-stapling точно будет. И поэтому отказаться ни от CRL, ни от OCSP не получается – просто потому, что серверы не обязаны опрашивать и отвечать. Ну и еще один аспект: если в вебе с этим нормально, то в почте всё плохо, а в FTP даже слов таких не знают.

Проблема того, что сервер не обязан отвечать, может решиться добавлением в сертификат еще одного поля – так как оно еще не утряслось, у него просто номер, — в котором мы говорим клиенту, что сервер таки обязан ответить, и если он не ответил, считать этот сертификат невалидным.

Вот это всё вместе теоретически может начать работать, но пока еще мало распространено.

Google и Mozilla, так как им всё это не нравится, сделали свой CRL. И зашили его в браузер. Огонь вообще! Это работает быстро, ну и на этом все плюсы заканчиваются. Для того чтобы не помереть, они не запихивают в него DV-сертификаты. То есть если DV-сертификат отозван, они считают – ну и ладно.

Так что если DV-сертификат отозван и при этом нет OSCP-степлинга, Chrome об этом не скажет – он посчитает этот сертификат нормальным. На самом деле, правильно пользоваться OSCP-степлингом иOCSP Must Staple флагом в сертификате.

Policy

Как мы уже знаем, если браузер смотрит в это поле и находит там определенные сочетания циферок и буковок, то он должен понять, что это EV-сертификат и, возможно надо сделать дополнительные вещи. Вот тут у нас указан Global Sign Repository – и иногда браузер должен сходить по указанному там адресу и получить ответ, что всё хорошо.

Root certificate

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

Откуда появляется вера в центры сертификации как в «хороших парней»? Все просто договорились, что вот таким-то организациям можно доверять. У каждого клиента есть список соответствия CA и публичного ключа. Таким образом, каждый клиент знает, что есть вот такой чувак и ключ для него такой. И так это всё и проверяется. То есть – просто записано, просто договорились, что верим.

Session id

До TLS 1.3 для решения этой проблемы использовались укороченные сессии. Когда сервер отвечает клиенту, он отдает ему Session ID. Если у клиента этот Session ID тоже есть, он отсылает его серверу и вот эта часть, которая в рамочке, пропускается. Потому что сервер запоминает контекст всей этой штуки и продолжает так, как будто это уже произошло.

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

Так это всё работает. Это побыстрее, но тоже есть проблемы, — возрастает нагрузка на сервер, ну и есть атаки с перехватом Session ID. Потому что этот Session ID идет по открытому каналу.

Session ticket

Еще для ускорения можно использовать Session Ticket — это в принципе то же самое, что и Session ID, только передается зашифрованный контекст, а не циферка, которую можно украсть. Бывает, что сессию установить не удалось, тогда придет алерт. С ними тоже связаны атаки на TLS, потому что алерты имеют определенную структуру и определенный размер.

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

Tls-handshake full vs resumed

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

Дополнительная защита

Вся структура TLS является уязвимой в одной точке – точке доверия, то есть вот эти вот сертификационные центры, рутовые сертификаты — если с ними что-то не то, всё разлетелось. Есть по сути две попытки с этим как-то бороться.

Как всё это тестить?

Инструментов для тестирования много, большинство из них не очень, вот эти плюс-минус ничего:

Маленький бонус

То, что не влезло.

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

Эта картинка — про ключевые слова. Из литературы можно рекомендовать очень крутую статью на русском языке «Ключи, шифры, сообщения: как работает TLS» – прочитать целиком вряд ли удастся, но в качестве справочника пригодится. Открыл, нашел что надо, почитал, ключевые слова узнал, пошел в википедию и на английском прочитал (на русском почему-то плохо написано).

На английском написано отлично: идея, зачем, почему, ссылочки. Не знаешь, что такое HSTS – иди в википедию, там будет ссылочки на статьи для Патриков, то есть чайников. Еще на RFC, но это читать невозможно. Общий смысл станет понятен даже из самой статьи в Википедии.

Вот и всё! Вы молодцы 🙂

Не отозван ли сертификат?

Самая интересная вещь – мы дошли до нее, ура! Самая прикольная, самая неработающая 🙂

Если говорить кратко, то сейчас здесь во всей инфраструктуре TLS очень большие проблемы, потому что: не работает ничего. И эту проблему как раз и хотят решать тем, чтобы срок действия сертификата сделать очень маленьким. Когда нужно отзывать сертификат?

Чаще всего – когда ваш приватный ключ утек. Ваш приватный ключ утек – вы попали. Надо сертификат отозвать, потому что если не отозвать, тот кто украл ваш ключ, сможет подсовывать клиентам ваш сертификат и представляться вами. Надо сказать: чуваки, я поменял свой ключ – тот сертификат не действителен!

Если сделать время действия сертификата очень маленьким, то в принципе можно не отзывать, а подождать, когда он кончится. Отсюда все эти экстремальные предложения с минутами и часами. Ну, а если у тебя сертификат на 3 года, а ключ украли на второй день – то три года кто-то сможет представляться тобой.

Как же проверить, отозван сертификат или нет?

Не протух ли сертификат?

После этого нам надо проверить, что сертификат не протух – это логично, ведь сертификаты выдаются на какое-то время.

Сейчас все certificate Authority договорились, что максимальный срок – 2 года (раньше было 3). Еще дальше они хотят сделать 1 год, а некоторые радикалы хотят, чтобы был месяц. Let’s Encrypt сейчас на 3 месяца выдает. А совсем радикальные радикалы хотят на каждое соединение новый сертификат выписывать.

Ответ клиента

Итак, Патрик проверил сертификаты и начинает отвечать Губке Бобу.

Если у клиента просили сертификаты, он их отдает. Дальше он отдает информацию для того, чтобы сделать ключики – так же, как сервер, clientKeyExchange. Поле CertificateVerify – неинтересная инфа на тему «как валидировать сертификат», в TLS 1.3 она и выглядит-то уже по-другому, потому что не сильно нужна.

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

Подпись

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

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

Сertificate transparency

Итак, всё хорошо, но Google не был бы Google, если бы не придумал еще одну технологию конкретно для себя. Она называется Сertificate Transparency. Откуда что идет: Google очень беспокоится о том, чтобы кто-нибудь не выписал плохой сертификат на него самого – чтобы именно Google не пострадал от того, что кто-то там выписывает какие-то нехорошие сертификаты.

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

Это не только технология, но и набор процессов. То есть Google говорит: ребята, вот у нас есть Сertificate Transparency, мы в него записываем только нормальные сертификаты – такие, где цепочка есть, цепочка правильная и всё нормально. Мы можем время записи Сertificate Transparency Log запихать в сертификат, чтобы клиент мог четче посмотреть, что вот этот сертификат в Transparency Log должен быть тогда-то.

Мы гарантируем, что это вот эта штука не редактируема обратно (из-за того, что блокчейн) – ну то есть нельзя взять и подменить старые записи, можно только добавлять новые. И давайте, ребята, кто-нибудь из вас будет периодически ходить по этому логу, и проверять, что там всё нормально, а если что-то не так, говорить нам и мы будем это править. А другие ребята пусть держат у себя всё это, потому что надо, чтобы было много мощностей на вот эту вот штуку.

Тот ли домен?

Тут всё понятно: если домен Wikipedia, а сертификат выписан на домен Plesk, то что происходит вообще? Кажется очевидным и капитанистым, но было несколько багов, когда клиенты это не проверяли. Сейчас, по счастью, такого бардака уже нет и стараются проверять все. Но опять-таки есть нюанс. Это SAN – Subject Alternative Name.

Тот ли тип использования?

Кроме проверки, тот ли это домен, не истёк ли срок годности и валидна ли подпись, из таких вещей, которые достаточно просто делаются, у нас еще есть пункт «тот ли тип использования».

Сертификаты бывают разные. То есть, если в Key Usage не указаны вот эти вот два параметра, то это – по идее! – должно влиять на то, как клиент с этим работает.

Key agreement – это как раз когда мы выписываем сеансовые ключи и договариваемся о них. Обычно вся эта коммуникация подписывается или шифруется вот этим вот публичным ключом, который чуть выше. Но если в key usage не прописан key agreement, то это означает, что ишьюер этого сертификата запрещает использовать этот сертификат для вот этого назначения.

Сейчас на практике это почти не встречается, то есть эти вещи у большинства сертификатов одинаковые, но тем не менее — в принципе могут быть и другие. И бывает, что сертификат НЕ подходит для чего-то. Для чего он подходит – написано здесь. Клиент должен это проверять.

Reinit

Что еще бывает в TLS-handshake в принципе? Иногда серверу бывает нужно инициализировать сессию повторно – чаще всего тогда, когда сертификат клиента был не нужен и вдруг стал нужен. Тогда сервер говорит: давай перезапустим. Ну и клиент может сказать еще раз Client Hello. В TLS 1.3 это тоже убрали, потому что тоже были атаки – атаки были везде!