Основы HTTPS, TLS, SSL. Создание собственных X.509 сертификатов. Пример настройки TLSv1.2 в Spring Boot

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

Время на прочтение

Привет, Хабр! В современном мире абсолютное большинство сайтов используют HTTPS (Google даже снижает рейтинг сайтов работающих по HTTP в поисковой выдаче), а подключение к различным системам происходит по протоколу TLS/SSL. Поэтому любой разработчик рано или поздно сталкивается с этими технологиями на практике. Данная статья призвана помочь разобраться, если вы совершенно не в курсе что это такое и как оно устроено. Мы разберем как работает соединение по протоколу TLS, как выпустить собственные сертификаты и настроем TLS в Spring Boot приложении. Поехали!

Что не так с HTTP?

Проблема протокола HTTP в том, что данные передаются по сети в открытом незашифрованном виде. Это позволяет злоумышленнику слушать передаваемые пакеты и извлекать любую информацию из параметров, заголовков и тела сообщения. Для устранения уязвимости был разработан HTTPS (S в конце значит Secure) — он, хоть не является отдельным протоколом, всего лишь HTTP поверх SSL (а позже TLS), позволяет безопасно обмениваться данными. В отличие от HTTP со стандартным TCP/IP портом 80, для HTTPS используется порт 443.

Протоколы

В стандартах название 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 соединения следующий:

MTLS

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

Открытый ключ ЭЦП

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

Сертификаты и безопасность веб-сайтов

Чаще всего сертификаты используются для веб-сайтов на основе HTTPS. Веб-браузер проверяет подлинность HTTPS веб-сервера, чтобы пользователь мог чувствовать себя в безопасности, что его / ее взаимодействие с веб-сайтом не подвергается перехватчикам и что веб-сайт является тем, кем он себя называет. Эта безопасность важна для электронной торговли. На практике оператор веб-сайта получает сертификат, обратившись в центр сертификации с запросом на подпись сертификата . Запрос на сертификат — это электронный документ, содержащий название веб-сайта, информацию о компании и открытый ключ. Провайдер сертификата подписывает запрос, создавая публичный сертификат. Во время просмотра веб-страниц этот общедоступный сертификат предоставляется любому веб-браузеру, который подключается к веб-сайту, и доказывает браузеру, что, по мнению провайдера, он выдал сертификат владельцу веб-сайта.

В качестве примера, когда пользователь подключается к https://www.example.com/с помощью своего браузера, если браузер не выдает предупреждение о сертификате, то пользователь может быть теоретически уверенным, что взаимодействие с https://www.example.com/эквивалентно взаимодействию с лицом, контактирующим с адресом электронной почты, указанным в общедоступном регистраторе в разделе «example.com», даже если это адрес электронной почты может не отображаться на веб-сайте. Никаких других гарантий не предполагается. Кроме того, взаимоотношения между покупателем сертификата, оператором веб-сайта и создателем контента веб-сайта могут быть ненадежными и не гарантируются. В лучшем случае сертификат гарантирует уникальность веб-сайта при условии, что сам веб-сайт не был скомпрометирован (взломан) или не нарушен процесс выдачи сертификата.

Провайдер сертификатов может выбрать выпуск трех типов сертификатов, каждый из которых требует своей степени строгости проверки. В порядке возрастания строгости (и, естественно, стоимости) это: проверка домена, проверка организации и расширенная проверка. Эти требования свободно согласовываются добровольными участниками CA / Browser Forum.

Уровни валидации

Провайдер сертификатов выдает сертификат, подтвержденный доменом (DV). покупателю, если покупатель может продемонстрировать один критерий проверки: право административно управлять затронутыми доменами DNS.

Проверка организации

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

Расширенная проверка

Чтобы получить сертификат расширенной проверки (EV), покупатель должен убедить поставщика сертификата его юридическая личность, включая ручную проверку человеком. Как и в случае с сертификатами OV, поставщик сертификатов публикует свои критерии проверки EV через свою политику сертификатов .

. До 2019 года основные браузеры, такие как Chrome и Firefox, обычно предлагали пользователям визуальную индикацию юридической идентичности, когда сайт представлял сертификат EV.. Это было сделано путем отображения юридического имени перед доменом и ярко-зеленого цвета, чтобы выделить изменение. Большинство браузеров не рекомендуют эту функцию, не создавая визуальной разницы для пользователя в зависимости от типа используемого сертификата. Это изменение последовало за проблемами безопасности, поднятыми судебными экспертами, и успешными попытками приобрести сертификаты EV для выдачи себя за известные организации, доказав неэффективность этих визуальных индикаторов и выявив потенциальные злоупотребления.

Слабые стороны

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

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

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

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

Полезность по сравнению с незащищенными веб-сайтами

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

Что происходит на практике

• Client Hello — клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA — Риверт-Шамир-Адлеман, DH — Диффи-Хеллмана, ECDH — Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES — Advanced Encryption Standard, 3DES — Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 — Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др.).Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.
• Server Hello — сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии. Для чего нужен идентификатор сессии? Как мы посмотрим далее, процесс установления TLS соединения затратен по времени и ресурсам. Предусмотрен механизм возобновления соединения с помощью отправки клиентом этого идентификатора. Если сервер тоже все еще хранит соответствующие настройки, то клиент и сервер смогут продолжить общение использую ранее выбранные алгоритмы и ключи.
• Certificate — сервер отправляет свой сертификат, а клиент производит проверку подписи удостоверяющего центра, проверку доверия к удостоверяющему центру, проверку указанного домена сайта с фактическим, срока действия, проверяет не был ли сертификат отозван.Что представляет из себя сертификат? Сертификат — это открытый ключ и другая информация о его владельце, а также Электронная Цифровая Подпись (ЭЦП) доверенного центра.Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, — вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA — Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом — это цепочка подписания. Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).
• Server Key Exchange — этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Ys=gслучайно выбранное сервером числоmod p, где mod — это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Yc=gслучайно выбранное клиентом числоmod p. После этого сервер считает Ycслучайно выбранное сервером числоmod p, а клиент Ysслучайно выбранное клиентом числоmod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:Сервер случайно генерирует число 6, передает клиенту числа p = 17, g = 3, Ys = 36mod 17 = 15Клиент случайно генерирует число 7 и возвращает серверу Yc = 37mod 17 = 11Сервер считает итоговое число 116mod 17= 8, и клиент 157mod 17 = 8
• Сервер случайно генерирует число 6, передает клиенту числа p = 17, g = 3, Ys = 36mod 17 = 15
• Клиент случайно генерирует число 7 и возвращает серверу Yc = 37mod 17 = 11
• Сервер считает итоговое число 116mod 17= 8, и клиент 157mod 17 = 8
• Server Hello Done — сервер сообщает, что начальный этап установки соединения завершен
• Client Key Exchange — как было уже сказано выше, когда сервер передал числа p, g, Ys в Server Key Echange, клиент передает свое число Yc в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret — предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.
• Change Cipher Spec — клиент говорит серверу, что он готов перейти на защищенное соединение.
• Finished — клиент зашифровывает симметричным ключом первое сообщение с MAC.
• Change Cipher Spec — сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.
• Finished — аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение
• После этого соединение считается установленным, и происходит передача полезной информации
• close_notify — служебное сообщение, которое одна сторона отправляет другой, как уведомление о том, что считает соединение разорванным и не будет принимать больше сообщения. Другая сторона в ответ обязана послать аналогичное сообщение close_notify.

SSL

Secure Sockets Layer (SSL) — это криптографический протокол, обеспечивающий безопасное общение пользователя и сервера по небезопасной сети. Располагается между транспортным уровнем и уровнем программы-клиента (FTP, HTTP и т.п.) (подробнее про уровни телекоммуникаций). Впервые был представлен публике в 1995 году, однако с 2015 года признан полностью устаревшим. На основе спецификации SSL 3.0 в 1996 был разработан TLS 1.0.

Использование 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:

И так, что же такое TLS? Transport Layer Security — это развитие идей, заложенных в протоколе SSL. На данный момент актуальной является версия TLSv1.2, с августа 2018 активно вводится TLSv1.3, тогда как TLSv1.1, TLSv1.0, SSLv3.0, SSLv2.0, SSLv1.0 находятся в статусе deprecated. Протокол обеспечивает услуги: приватности (сокрытие передаваемой информации), целостности (обнаружение изменений), аутентификации (проверка авторства). Достигаются они за счет гибридного шифрования, то есть совместного использования ассиметричного и симметричного шифрования.

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

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

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

Типы сертификатов

Роли корневого сертификата, i Промежуточный сертификат и сертификат конечного объекта, как в цепочке доверия.

Сертификат сервера TLS / SSL

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

• Субъект сертификата совпадает с именем хоста (то есть доменным именем), к которому клиент пытается для подключения;
• Сертификат подписан доверенным центром сертификации.

Основное имя хоста (доменное имя веб-сайта) указано как Общее имя в поле Тема сертификата. Сертификат может быть действителен для нескольких имен хостов (нескольких веб-сайтов). Такие сертификаты обычно называются сертификатами альтернативного имени субъекта (SAN) или сертификатами унифицированных коммуникаций (UCC) . Эти сертификаты содержат поле Альтернативное имя субъекта, хотя многие центры сертификации также помещают их в поле Общее имя субъекта для обратной совместимости. Если некоторые из имен хостов содержат звездочку (*), сертификат также может называться групповым сертификатом.

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

В соответствии с приложениями сертификаты SSL можно разделить на три типа:

• SSL для проверки домена;
• SSL для проверки организации;
• SSL для расширенной проверки.

Сертификат клиента TLS / SSL

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

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

Сертификат электронной почты

В протоколе S / MIME для защищенной электронной почты отправителям необходимо определить, какой открытый ключ использовать для каждого получателя. Они получают эту информацию из сертификата электронной почты. Некоторые общественно доверенные центры сертификации предоставляют сертификаты электронной почты, но чаще всего S / MIME используется при взаимодействии внутри данной организации, и эта организация имеет собственный ЦС, которому доверяют участники этой системы электронной почты.

Сертификат EMV

Платежные карты EMV предварительно загружены сертификатом эмитента карты, подписанным центром сертификации EMV для проверки подлинности платежной карты во время платежной транзакции. Сертификат EMV CA загружается в карточные терминалы ATM или POS и используется для проверки сертификата эмитента карты.

Сертификат подписи кода

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

Квалифицированный сертификат

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

Корневой сертификат

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

Промежуточный сертификат

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

Конечный объект или конечный сертификат

Любой сертификат, который нельзя использовать для подписи других сертификатов. Например, сертификаты сервера и клиента TLS / SSL, сертификаты электронной почты, сертификаты подписи кода и квалифицированные сертификаты являются сертификатами конечных объектов.

Самоподписанный сертификат

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

Двусторонний TLS

Двусторонний TLS или Two Way TLS или mutual TLS (mTLS) означает проверку сертификата клиента. Сервер после своего сообщения Certificate посылает запрос сертификата клиента CertificateRequest. Клиент в ответ отправляет Certificate, сервер производит проверку, аналогичную проверке сертификата сервера клиентом. Далее настройка TLS происходит в описанном выше порядке.

Центры сертификации

Процедура получения сертификата открытого ключа

В модели доверия X.509 центр сертификации (CA) отвечает за подписание сертификатов. Эти сертификаты действуют как вступление между двумя сторонами, что означает, что ЦС действует как доверенная третья сторона. ЦС обрабатывает запросы от людей или организаций, запрашивающих сертификаты (называемые подписчиками), проверяет информацию и потенциально подписывает сертификат конечного объекта на основе этой информации. Для эффективного выполнения этой роли ЦС должен иметь один или несколько широко доверенных корневых сертификатов или промежуточных сертификатов и соответствующие закрытые ключи. Центры сертификации могут достичь этого широкого доверия, включив свои корневые сертификаты в популярное программное обеспечение или получив перекрестную подпись от другого центра сертификации, делегирующего доверие. Другим центрам сертификации доверяют в относительно небольшом сообществе, таком как бизнес, и они распространяются с помощью других механизмов, таких как Windows Групповая политика.

Центры сертификации также несут ответственность за поддержание актуальной информации об отзыве сертификатов, которые они выпустили, указывает, действительны ли сертификаты. Они предоставляют эту информацию через онлайн-протокол состояния сертификатов (OCSP) и / или списки отзыва сертификатов (CRL). Некоторые из крупных центров сертификации на рынке включают IdenTrust, DigiCert и Sectigo.

Закрытый ключ ЭЦП

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

В ключевой паре открытая и закрытая части привязаны друг к другу.

Использование в Европейском Союзе

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

Выпускаем собственные сертификаты

Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем «password» длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:

openssl genrsa -aes256 -passout pass:password -out CA-private-key.key 4096

Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:

• .key — для приватного ключа
• .csr — для запроса на подпись сертификата
• .pem — для сертификата в Privacy Enchanced Mail формате. Записывается в base64 между ——BEGIN CERTIFICATE—— и ——END CERTIFICATE——. Также существует Distinguished Encoding Rules (DER) формат, где информация хранится как binary.
• p12 — для хранилища ключей с сертификатами (keystore) и хранилища доверенных сертификатов (truststore) в формате Public-Key Cryptography Standards 12.

Далее создадим новый запрос на подпись сертификата CA-certificate-signing-request.csr, передавая информацию о субъекте «CN=Certificate authority» (если не указывать ключ -subj вас попросят указать: Сountry (C), Locality (L), Organisation (O), Organisation Unit (OU), Common Name (CN), Email, Challenge password — все поля, кроме CN опциональны), приватный ключ и пароль от него:

Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.

openssl x509 -req -in CA-certificate-signing-request.csr -signkey CA-private-key.key -passin pass:password -days 1 -out CA-self-signed-certificate.pempemE

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

openssl genrsa -aes256 -passout pass:password -out Server-private-key.key 4096
openssl req -new -key Server-private-key.key -passin pass:password -subj «/CN=localhost/» -out Server-certificate-signing-request.csrt $3

openssl genrsa -aes256 -passout pass:password -out Client-private-key.key 4096
openssl req -new -key Client-private-key.key -passin pass:password -subj «/CN=Client/» -out Client-certificate-signing-request.csr

Подпишем запросы нашим сертификатом CA. Ключ CAcreateserial отвечает за создание файла (в данном случае CA-self-signed-certificate.srl) , в котором будет храниться серийный номер для следующего подписываемого этим сертификатом запроса. Серийный номер для текущего же сертификата сгенерируется случайно.

openssl x509 -req -in Server-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -CAcreateserial -days 1 -out Server-certificate.pemt $4
openssl x509 -req -in Client-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -days 1 -out Client-certificate.pem

После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем «password»:

openssl pkcs12 -export -in Server-certificate.pem -inkey Server-private-key.key -passin pass:password -passout pass:password -out Server-keystore.p12

Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:

keytool -import -file CA-self-signed-certificate.pem -keystore Server-truststore.p12 -storetype PKCS12 -storepass password -noprompt

Для удобства, все описанные выше действия упакованы в bash script.

TLSv1

Стоит отметить, что все выше написанное относится к TLSv1.2, которая начинает понемногу устаревать. В 2018 году была разработана новая версия 1.3 в которой: были запрещены уже ненадежные алгоритмы, ускорен процесс соединения, переработан протокол рукопожатия и др. Интернет медленно но верно обновляется до TLSv1.3, однако все еще большинство сайтов работают по протоколу TLSv1.2. Поэтому информация в этой статье остается актуальной.

Анонс

За последние годы инфраструктура приватных ключей 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 в сети Интернет:

Настройка TLS в Spring Boot приложении

Основой для нашего проекта послужит шаблон с https://start.spring.io/ с одной лишь зависимостью Spring Web. Для включения TLS указываем в application.properties:

После этого указываем Spring тип keystore, путь к нему и пароль:

Для проверки доступа создадим минимальный контроллер:

Запускаем проект. Попробуем сделать запрос с помощью curl:

Как видим, curl не доверяет сертификату сервера. Сделаем еще один запрос, указав наш CA сертификат в ключе —cacert:

curl —cacert CA-self-signed-certificate.pem https://localhost/

Hello, world!

На этот раз все сработало, TLS в Spring Boot работает! Мы на этом не остановимся, добавим в приложение аутентификацию клиента (указываем truststore):

Запускаем и снова пытаемся выполнить запрос:

curl —cacert CA-self-signed-certificate.pem https://localhost/

curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

Очевидно, что сервер закрыл соединение, так как curl не предоставил никакого сертификата. Дополним запрос клиентским сертификатом и его закрытым ключом:

curl —cacert CA-self-signed-certificate.pem —cert Client-certificate.pem:password —key Client-private-key.key https://localhost/

Hello, world!

Стандарты

Отдел компьютерной безопасности Национального института стандартов и технологий (NIST ) предоставляет руководящие документы для сертификатов открытых ключей:

• SP 800-32 Введение в технологию открытых ключей и Федеральная инфраструктура PKI
• SP 800-25 Федеральное агентство по использованию технологии открытого ключа для цифровых подписей и аутентификации

Образец сертификата

Это пример полученного декодированного сертификата SSL / TLS с веб-сайта SSL.com. Общее имя эмитента (CN) отображается как SSL.com EV SSL Intermediate CA RSA R3, идентифицируя его как сертификат расширенной проверки (EV). Подтвержденная информация о владельце веб-сайта (SSL Corp) находится в поле Тема. Поле X509v3 Subject Alternative Nameсодержит список доменных имен, на которые распространяется сертификат. Поля Расширенное использование ключа X509v3и Использование ключа X509v3показывают все подходящие варианты использования.

Термины

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

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

CA (Certificate Authority)

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

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

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

509 certificate

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

• Сертификаты, которые относятся к удостоверяющим центрам, называются корневыми (root certificates) или промежуточными (intermediate certificates) в зависимости от типа CA.
• Приватным ключом корневого CA можно подписывать как сертификаты промежуточных CA, так и сертификаты конечных точек (end-point). Обычно конечные сертификаты подписываются приватными ключами промежуточных CA.
• Приватными ключами конечных точек нельзя подписывать другие сертификаты.
• Сертификаты выдаются в формате X.509:Такой сертификат содержит структуру данных, которая состоит из идентификационных данных (Identity), дополнительных расширений (Extensions) и публичного ключа (Public Key) его владельца.Сертификат подписывается корневым или промежуточным CA и его подпись связывает Identity владельца с его публичным ключом.
• Такой сертификат содержит структуру данных, которая состоит из идентификационных данных (Identity), дополнительных расширений (Extensions) и публичного ключа (Public Key) его владельца.
• Сертификат подписывается корневым или промежуточным CA и его подпись связывает Identity владельца с его публичным ключом.

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

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

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

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

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

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

X509v3 Key Usage:  Digital Signature, Key Encipherment

X509v3 Extended Key Usage: Server Authentication, Client Authentication

X509v3 Basic Constraints: CA:FALSE

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

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

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

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

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

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 находится в списке доверенных удостоверяющих центров:
• Под номером 1 идет конечный сертификат для сайта sushkov.ru
• Номер 2 — промежуточный сертификат CA
• Номер 3 — корневой сертификат CA находится в списке доверенных удостоверяющих центров:

Как найти и выгрузить ключи на компьютер?

Чаще всего появляется необходимость выгрузить открытый ключ, например, чтобы предоставить его контрагентам для проверки ЭЦП. На токене сертификат проверки ключа скрыт. Как его открыть? Сделать это можно через свойства браузера или программу КриптоПро CSP. Чтобы экспортировать ключ, в первую очередь необходимо подключить токен к компьютеру.

Через свойства браузера:

• В ОС Windows необходимо открыть: «Пуск» — «Панель управления» — «Свойства браузера».
• В появившемся окне выбрать вкладку «Содержание», а далее — «Сертификаты».
• Появится список сертификатов, в котором следует выбрать нужный, а затем нажать кнопку «Экспорт».
• Появится окно «Мастер экспорта сертификатов», где нужно выбрать «Не экспортировать закрытый ключ», если это не требуется.
• Выбрать формат файла «Файлы в DER-кодировке X.509 (.CER)».
• Выбрать место хранения ключа и сохранить.

Через КриптоПро CSP:

• В ОС Windows надо перейти в «Пуск» — «Панель управления» — «КриптоПро CSP».
• В открывшемся окне следует выбрать вкладку «Сервис» и нажать «Просмотреть сертификаты в контейнере».
• Через кнопку «Обзор» нужно выбрать контейнер.
• В окне «Сертификат для просмотра» следует нажать кнопку «Свойства» и на вкладке «Состав» нажать «Копировать в файл».
• Далее порядок действий в окне «Мастер экспорта сертификатов» аналогичный: выбрать, нужно ли сохранять закрытый ключ, установить формат и определить место хранения.

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

Выгрузка закрытого ключа через свойства браузера выполняется по тому же алгоритму, что и в случае с открытым. Только в окне «Мастер экспорта сертификатов» нужно выбрать «Экспортировать закрытый ключ». А порядок действий при выгрузке из КриптоПро CSP следующий:

• В ОС Windows нажать «Пуск» перейти на «Панель управления» и выбрать «КриптоПро CSP».
• Далее — вкладка «Сервис» и кнопка «Скопировать контейнер».
• Через кнопку «Обзор» нужно выбрать контейнер и подтвердить (потребуется ввести PIN-код).
• Затем нужно ввести название копии закрытого ключа и нажать «Готово».
• Далее нужно выбрать, куда будет записан ключ, установить пароль для обеспечения дополнительной защиты и подтвердить действия.

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

Заказав электронную цифровую подпись в СберКорус, вы сможете самостоятельно настроить компьютер для работы с ЭЦП, посмотрев видеоинструкцию. При возникновении сложностей мы поможем настроить компьютер бесплатно. А также в любое время проконсультируем по интересующим вопросам.

Корневые программы

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

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

• Корневая программа Microsoft
• Корневая программа Apple
• Корневая программа Mozilla
• Корневая программа Oracle Java
• Adobe AATL Adobe Approved Trust List и EUTL корневые программы (используются для подписи документов)

Браузеры, отличные от Firefox, обычно используют возможности операционной системы, чтобы решить, каким центрам сертификации можно доверять. Так, например, Chrome в Windows доверяет центрам сертификации, включенным в корневую программу Microsoft, а в macOS или iOS Chrome доверяет центрам сертификации в корневой программе Apple. Edge и Safari также используют соответствующие хранилища доверенных сертификатов операционной системы, но каждый из них доступен только в одной ОС. Firefox использует хранилище доверенных сертификатов Mozilla Root Program на всех платформах.

Корневая программа Mozilla является общедоступной, и ее список сертификатов является частью веб-браузера Firefox с открытым исходным кодом, поэтому он широко используется за пределами Firefox. Например, хотя общей корневой программы Linux не существует, многие дистрибутивы Linux, такие как Debian, включают пакет, который периодически копирует содержимое списка доверия Firefox, который затем используется приложениями.

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

Заключение

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

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

Итоги

В данной статье мы разобрались как работает протокол TLS и для чего он нужен. На практике научились создавать собственные сертификаты и использовать их в Java приложении на Spring Boot. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!