Анонс

За последние годы инфраструктура приватных ключей PKI (Public Key Infrastructure) незаметно окружила нас со всех сторон:

• Большинство сайтов в сети Интернет используют HTTPS протокол. Для его работоспособности необходимо получать сертификаты из удостоверяющих центров (Certificate Authority)

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

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

Давайте разберемся как работают системы PKI, т.к. они еще долго будут актуальны для обеспечения аутентификации и безопасной передачи данных. В данной статье рассмотрим теорию и в качестве примера PKI возьмём самую известную в мире реализацию PKI - HTTPS протокол в сети Интернет. В качестве удостоверяющего центра будем использовать бесплатный Let's Encrypt. В следующей статье  "Сам себе PKI: Практика на примере OpenSSL и CA Smallstep" перейдем к практике и организуем безопасную передачу данных на основе TLS протокола:

• Сначала вручную (с помощью OpenSSL) пройдем цепочку генерации и использования самоподписанных сертификатов в HTTPS сервере. 

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

На схеме упрощенная система PKI для организации HTTPS в сети Интернет: 

Термины

PKI (Public Key Infrastructure)

Системы PKI построены на криптографии, которая использует пару ключей: публичный (public key) и приватный (private key). Глобальная цель систем PKI - связать пользователей и соответствующие публичные ключи. Пользователями могут быть как реальные люди, так и IP адреса устройств, доменные имена компьютеров и т.д. Разбор принципов криптографии выходит за рамки данной статьи, но для наших целей важно понимать несколько принципов:

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

• Публичный ключ можно и нужно распространять открыто. Приватный ключ владелец должен хранить в секрете.

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

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

CA (Certificate Authority)

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

• Automatic Certificate Management Environment (ACME) 

• Simple Certificate Enrollment Protocol (SCEP)

• Enrollment over Secure Transport (EST)

Каждый браузер и операционная система хранит предопределенный список доверительных удостоверяющих центров. Эти списки общедоступны, например, вот список для браузера Firefox от компании Mozilla. Найдем в этом списке компанию Let's Encrypt (Internet Security Research Group), о которой подробно будем говорить далее. Смотрим на ее корневой сертификат, он называется "ISRG  Root X1" и запоминаем его хеш 96BCE...08C6:

Теперь запускаем браузер Firefox, заходим в хранилище сертификатов (меню Settings / Privacy & Security / View Certificates) и видим тот же корневой сертификат с тем же хешом (fingerprint):

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

X.509 certificate

Факты которые необходимо знать про сертификаты:

• Сертификаты, которые относятся к удостоверяющим центрам, называются корневыми (root certificates) или промежуточными (intermediate certificates) в зависимости от типа CA.

• Приватным ключом корневого CA можно подписывать как сертификаты промежуточных CA, так и сертификаты конечных точек (end-point). Обычно конечные сертификаты подписываются приватными ключами промежуточных CA.

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

• Сертификаты выдаются в формате X.509:

  • Такой сертификат содержит структуру данных, которая состоит из идентификационных данных (Identity), дополнительных расширений (Extensions) и публичного ключа (Public Key) его владельца.

  • Сертификат подписывается корневым или промежуточным CA и его подпись связывает Identity владельца с его публичным ключом.

Схематично X.509 сертификат имеет следующую структуру: 

Рассмотрим подробнее атрибуты сертификата. Для просмотра информации о сертификате сайта есть как онлайн средства, о которых поговорим далее, так и офлайн утилиты. Здесь приведу вывод утилиты OpenSSL, которая доступна для всех популярных операционных систем и будет подробно рассмотрена в следующей статье: "Практика на примере OpenSSL и CA Smallstep". Для примера посмотрим на сертификат моего сайта:

• openssl s_client -connect sushkov.ru:443

Главные атрибуты, на которые надо обратить внимание при просмотре сертификата - это кто, кому и на какой срок выдал сертификат: 

• Какой CA выдал сертификат:

Issuer: C=US,O=Let's Encrypt,CN=R3

• Имя пользователя. Раньше для этого использовалось поле Subject. Теперь используется его расширение: 

X509v3 Subject Alternative Name: DNS:sushkov.ru, DNS:www.sushkov.ru

• Срок действия:

Validity Not After : Jun 17 18:51:29 2022 UTC

Остальные поля не столь наглядны и, в основном, используются для установки безопасного HTTPS соединения с сайтом:

•  Версия:

Version: 3 (0x2)

• Способы использования сертификата:

X509v3 Key Usage:  Digital Signature, Key Encipherment

X509v3 Extended Key Usage: Server Authentication, Client Authentication

• Не является CA сертификатом, а значит - это конечный сертификат

X509v3 Basic Constraints: CA:FALSE

• Имя пользователя (Subject):

X509v3 Subject Alternative Name: DNS:sushkov.ru, DNS:www.sushkov.ru

• Публичный ключ пользователя:

Subject Public Key: / блок с бинарными данными /

• Уникальные ключи для Subject и CA, используются в процессе проверки сертификатов (certificate path validation):

X509v3 Subject Key Identifier: / блок с бинарными данными /

X509v3 Authority Key Identifier: / блок с бинарными данными /

• Адрес для получения статуса отзыва (revocation status) X.509 сертификатов:

OCSP - URI:http://r3.o.lencr.org 

• Адрес для получения сертификата CA: 

CA Issuers - URI:http://r3.i.lencr.org/ 

• Параметры Certificate Transparency

RFC6962 Certificate Transparency SCT

• Цифровая подпись сертификата, которая записана удостоверяющим центром:

Signature Algorithm: SHA256-RSA / блок с бинарными данными /

Certificate chain / certificate path validation

• Цепочкой сертификатов называют последовательность из корневого сертификата CA, промежуточного сертификата CA и конечного сертификата CA.

• Обычно конечный сертификат подписан приватным ключом промежуточного CA, сертификат промежуточного CA подписан приватным ключом корневого CA, сертификат корневого CA подписан собственным приватным ключом. Таким образом корневой сертификат является самоподписанным сертификатом (Self-signed certificate) и в нем совпадают Issuer name и Subject name.

• В общем случае может быть несколько промежуточных CA, но это сильно усложняет топологию.

• Для установления HTTPS соединения сайт может посылать браузеру как цепочку из промежуточного и конечного сертификата, так и только конечный сертификат. В любом случае при установке HTTPS соединения (TLS handshake) браузер должен проверить всю цепочку до корневого сертификата в своем списке доверенных корневых удостоверяющих центров (Trusted Root Certification Authorities). Этот процесс называется certificate path validation. Пример проверки цепочки сертификатов для моего сайта можно посмотреть на сайтах, которые специализируются на проверке сертификатов, например, сайт показывает полную цепочку сертификатов :

  • Под номером 1 идет конечный сертификат для сайта sushkov.ru

  • Номер 2 - промежуточный сертификат CA

  • Номер 3 - корневой сертификат CA находится в списке доверенных удостоверяющих центров:

Протоколы 

SSL / TLS

В стандартах название SSL протокола было заменено на TLS в 1999 году, но до сих пор используется как синоним технологии. Наиболее актуальный стандарт TLS 1.3, опубликованный в 2018. TLS обеспечивает три главных принципа безопасного обмена данными:

• Сonfidentiality - конфиденциальность данных обеспечивается шифрованием трафика между браузером и сайтом. 

• Authentication - аутентификация сайта. CA выдает сертификаты для сайтов, к которым у владельца сертификата действительно есть доступ. Для этой проверки могут использоваться разные механизмы. Например, во время процесса выдачи сертификата владельцу сайта может быть предложено поместить по определенному адресу на сайте файлы с определенным содержанием. 

• Integrity - целостность или защита от изменения данных. Эта защита является частью алгоритма обмена шифрованными данными, при котором в сообщение включается MAC (message authentication code). 

HTTPS 

Если трафик HTTP шифруется и передается с помощью протокола TLS, то он называется HTTPS. При этом шифруются как сами данные, так и HTTP заголовки.

TLS handshake

Для установления TLS соединения используется процесс, который называется TLS handshake. В TLS handshake участвуют клиент (браузер или web-приложение) и HTTPS сервер. Алгоритм установки HTTPS соединения следующий: 

• Клиент посылает сообщение 'client hello', которое содержит:

  • Версии поддерживаемых протоколов TLS (TLS 1.0, 1.2, 1.3, etc.)

  • Набор поддерживаемых алгоритмов шифрования (cipher suite)

  • Производьную строку "client random"

• Сервер отвечает сообщением 'server hello'. Сообщение содержит:

  • Сертификат сервера

  • Выбранный сервером алгоритм шифрования (cipher suite)

  • Произвольную строку "server random"

• Клиент аутентифицирует сервер. Для этого проверяет сертификат сервера: 

  • Осуществляется процесс проверки цепочки сертификатов (certificate path validation)

  • Проверяется, что запрашиваемое из браузера доменное имя присутствует в сертификате в списке Subject Alternative Name 

  • Проверяется срок действия сертификата

  • Проверяется revocation статус сертификата. Для этого браузер использует список отозванных сертификатов CRL (Certificate Revocation List) или протокол OCSP (Online Certificate Status Protocol)

  • Ряд дополнительных атрибутов таких как policy, restrictions и т.п. 

• Если все проверки прошли успешно, клиент генерирует premaster secret зашифровывает публичным ключом сервера и отправляет 'change cipher spec'.

• Сервер расшифровывает premaster secret своим приватным ключом.

• Клиент и сервер генерируют сессионный ключ (session key), используя параметры client random, server random и premaster secret. Сессионный ключ получается одинаковым у клиента и сервера и будет использоваться для симметричного шифрования данных после завершения процедуры TLS handshake.

• Клиент и сервер отправляют друг другу сообщение "finished", зашифрованное session key.

• На этом процедура TLS handshake завершена и дальнейший обмен данными шифруется с помощью session key.

mTLS 

mTLS (Mutual TLS ) - это дополнительный шаг установки TLS соединения, при котором происходит проверка сервером клиентского сертификата. Подробнее этот процесс разберем на практике в следующей статье: "Практика на примере OpenSSL и CA Smallstep".

Использование CA Let's Encrypt 

Теперь запросим бесплатный сертификат из удостоверяющего центра Let's Encrypt и разберём процесс организации HTTPS соединения между браузером и моим сайтом https://sushkov.ru. На схеме показана топология CA Let's Encrypt и процесс получения  сертификатов: 

• Корневой приватный ключ для корневого сертификата "ISRG Root X1" хранится offline, им подписываются intermediate сертификаты, в Let's Encrypt их несколько. R3 - один из них.

• С помощью intermediate ключей уже подписываются конечные (endpoint) сертификаты. 

Предусловия для работоспособности сценария: 

0. Корневой сертификат Let's Encrypt должен быть помещен в браузер в список "Trusted Root Certification Authorities". Это мы уже уже видели. 

1. Первым шагом владелец сайта запускает утилиту certbot, которая взаимодействует с его сайтом и CA Let's Encrypt.

2. Certbot просит владельца поместить два файла с определенными именами и содержимом по указанному адресу на сайте.  Если владелец это сделал, значит он подтвердил, что имеет к нему доступ. Пример запроса для одного из файлов:

3. Certbot проверяет наличие файлов.

4. Certbot генерирует приватный ключ, публичный ключ и запрос на сертификат (CSR) и отправляет его на подпись CA Let's Encrypt.

5. CA подписывает сертификат своим приватным ключом и возвращает в сertbot.

6. После этого владелец помещает сертификат и приватный ключ на сайт. Как конкретно это происходит зависит от платформы, на которой хостится сайт. Пример загрузки сертификата и приватного ключа у провайдера RU-CENTER:

7. Теперь при доступе из браузера к сайту https://sushkov.ru будет устанавливаться TLS соединение .

8. Обмен данными происходит по шифрованному каналу.

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

Тут же можно посмотреть на цепочку сертификатов:

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

Это вывод сайта компании DigiCert:

Заключение

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

• Не надо бездумно добавлять сертификаты в список доверенных CA! А это очень просто сделать в Windows, запустив на выполнение файл с расширением "CRT". Ведь, если в списке окажется сертификат злоумышленника, то он сможет организовать, так называемую, атаку MITM (Man-in-the-middle)  и незаметно читать все сообщения в соцсетях и мессенджерах, получать пароли от банковских систем.

• Как понять, что используется сертификат злоумышленника? Смотрим на сертификат сайта и видим, что его выдал CA не из эталонного списка, а попавший туда позже. На картинке ниже видим Касперского на сайте Росбанка. Касперский явно не является доверительным CA из списка браузера. Отсюда делаем вывод, что он установил свой сертификат позже. Но Касперскому мы верим, что он ничего плохого делать не будет, а просто проверит на вирусы!)

• Основной вывод - тщательно проверяйте сертификаты сайтов, если они имеют важное значение в вашей жизни и финансовом благополучии!

• Клиент посылает сообщение 'client hello', которое содержит:

  • Версии поддерживаемых протоколов TLS (TLS 1.0, 1.2, 1.3, etc.)

  • Набор поддерживаемых алгоритмов шифрования (cipher suite)

  • Производьную строку "client random"

• Сервер отвечает сообщением 'server hello'. Сообщение содержит:

  • Сертификат сервера

  • Выбранный сервером алгоритм шифрования (cipher suite)

  • Произвольную строку "server random"

• Клиент аутентифицирует сервер. Для этого проверяет сертификат сервера: 

  • Осуществляется процесс проверки цепочки сертификатов (certificate path validation)

  • Проверяется, что запрашиваемое из браузера доменное имя присутствует в сертификате в списке Subject Alternative Name 

  • Проверяется срок действия сертификата

  • Проверяется revocation статус сертификата. Для этого браузер использует список отозванных сертификатов CRL (Certificate Revocation List) или протокол OCSP (Online Certificate Status Protocol)

  • Ряд дополнительных атрибутов таких как policy, restrictions и т.п. 

• Если все проверки прошли успешно, клиент генерирует premaster secret зашифровывает публичным ключом сервера и отправляет 'change cipher spec'.

• Сервер расшифровывает premaster secret своим приватным ключом.

• Клиент и сервер генерируют сессионный ключ (session key), используя параметры client random, server random и premaster secret. Сессионный ключ получается одинаковым у клиента и сервера и будет использоваться для симметричного шифрования данных после завершения процедуры TLS handshake.

• Клиент и сервер отправляют друг другу сообщение "finished", зашифрованное session key.

• На этом процедура TLS handshake завершена и дальнейший обмен данными шифруется с помощью session key.

Предыдущие несколько абзацев текста до картинки задублировались без моего ведома...