Источник: https://github.com/AnaktaCTF/CTF/blob/main — WEB/Digital certificates in SSL_TLS.md

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

TLS был разработан на базе SSL как более современная и безопасная версия после обнаружения уязвимостей в SSLv3. Сегодня под термином SSL часто подразумевают именно TLS.

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

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

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

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

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

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

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

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

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

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

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

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

Здесь и вступает в игру цифровой сертификат. Он играет роль удостоверения личности, как паспорт в реальной жизни. Паспорт подтверждает, что фотография принадлежит конкретному человеку, и эта связь заверена государственной структурой. Аналогично, цифровой сертификат подтверждает принадлежность публичного ключа конкретному субъекту — будь то домен или организация. При этом подпись ставит доверенный центр сертификации, гарантируя, что ключ можно использовать безопасно.

Цифровые сертификаты упрощают распространение и проверку публичных ключей и являются неотъемлемой частью инфраструктуры SSL/TLS.

Как получить цифровой сертификат?

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

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

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

Пример использования

Чтобы на практике понять, как работает SSL, рассмотрим типичный сценарий подключения браузера к серверу через защищённое соединение HTTPS. Такой механизм ежедневно используется в Интернете — будь то отправка писем через Gmail, онлайн-покупки или вход в онлайн-банк.

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

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

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

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

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

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

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

Ограничения по использованию сертификатов

Обычно цифровой сертификат привязан к одному конкретному полному доменному имени (FQDN). Это значит, что сертификат, выданный для адреса www.mysite.com, не сможет защитить, к примеру, mail.mysite.com или сайт с другим доменом — www.othersite.com.

Если возникает необходимость защитить не только основной домен, но и его поддомены, чаще всего используют Wildcard-сертификаты. Такой сертификат охватывает все поддомены указанного доменного имени. Например, сертификат, выписанный для *. mysite.com, подойдёт для следующих поддоменов:

• mail.mysite.com

• www.mysite.com

• ftp.mysite.com

• api.mysite.com и других.

Однако Wildcard-сертификат не позволит работать одновременно с доменами разных зон — например, для mysite.com и myothersite.com его использовать уже нельзя.

Чтобы защитить несколько независимых доменов в рамках одного сертификата, применяются сертификаты с поддержкой SAN (Subject Alternative Name). Они дают возможность добавить к основному домену ещё несколько альтернативных. Например, один SAN-сертификат может обеспечить защиту для таких адресов:

• www.mysite.com

• www.mysite.org

• www. mysite.net

• www. mysite.co

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

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

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

Кодировка сертификатов и расширения файлов

Сертификаты могут быть закодированы в различных форматах, например:

• В бинарном формате (.DER)

• В ASCII-формате base64 (.PEM)

Кроме того, существуют несколько распространённых расширений файлов сертификатов:

• .DER

• .PEM (Privacy Enhanced Mail)

• .CRT

• .CERT

Важно отметить, что расширение файла не всегда указывает на его кодировку. Это означает, что файл с расширением .CRT может быть закодирован в формате .DER или .PEM.

Если вам нужно узнать, в какой кодировке находится ваш файл — .DER или .PEM, вы можете использовать утилиту OpenSSL. Она поможет определить формат файла или конвертировать его в нужный. Простой способ — открыть файл в текстовом редакторе: если вы видите читаемый текст (ASCII), значит, это файл в формате .PEM. Если же содержимое выглядит как набор непонятных символов, это бинарный формат, то есть .DER.

###Примеры сертификатов

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

Важно помнить, что все сертификаты начинаются строкой -----BEGIN CERTIFICATE----- и заканчиваются строкой -----END CERTIFICATE-----. Эти строки являются маркерами, указывающими на начало и конец сертификата.

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

Корневые сертификаты могут существовать как отдельные файлы, но также они часто объединяются в пакеты для удобства. В Linux-системах на основе Debian такие корневые сертификаты обычно хранятся в директории /etc/ssl/certs в файле, называемом ca-certificates.crt. Этот файл создаётся системой и обновляется с помощью команды update-ca-certificates, которая добавляет новые сертификаты.

Файл ca-certificates.crt содержит множество корневых сертификатов и выглядит примерно так:

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

mosquitto_pub --cafile /etc/ssl/certs/ca-certificates.crt
mosquitto_pub --capath /etc/ssl/certs/

Центры сертификации (ЦС) могут создавать дочерние ЦС, которые также имеют право выдавать сертификаты своим клиентам.

Чтобы подтвердить подлинность сертификата, клиенту нужно проверить подписи сертификатов всех ЦС, составляющих цепочку (chain) сертификации. Хотя у клиента может быть установлен корневой сертификат, скорее всего, у него не будет сертификатов промежуточных ЦС.

В связи с этим сертификаты часто поставляются в виде пакетов (bundle). Такой пакет включает в себя сертификаты всех ЦС, которые находятся в цепочке доверия. Обычно этот файл называется CA-Bundle.crt.

Если вам предоставили индивидуальные сертификаты, вы можете сами объединить их в пакет, чтобы обеспечить правильную цепочку сертификации.