SSL/TLS и PKI

Как работают SSL/TLS и PKI, на что обращать внимание при мониторинге и как оперативно выявлять угрозы, прямо в шифрованном трафике.

SSL/TLS и PKI — это фундамент безопасного интернета, обеспечивающий шифрование данных, аутентификацию серверов и защиту от перехвата информации.

SSL/TLS

SSL (Secure Sockets Layer) и его преемник TLS (Transport Layer Security) — это криптографические протоколы, обеспечивающие:

  • Шифрование — предотвращает перехват данных (например, логинов, платежей).

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

  • Целостность данных — защищает от подмены информации в передаваемых пакетах.

Эволюция протоколов:

  • SSL (устарел, небезопасен) → TLS 1.0/1.1 (уязвимы, deprecated) → TLS 1.2 (широко используется) → TLS 1.3 (современный стандарт, быстрее и безопаснее).

Процесс установки защищённого соединения

  1. ClientHello — клиент отправляет список поддерживаемых шифров и версий TLS.

  2. ServerHello — сервер выбирает подходящий алгоритм и отправляет свой сертификат.

  3. Проверка сертификата — клиент убеждается, что сервер доверенный (через цепочку CA).

  4. Обмен ключами — формируется общий секретный ключ (например, через Diffie-Hellman).

  5. Шифрование данных — дальнейший обмен идёт в зашифрованном виде.

Цепочка доверия (Certificate Chain of Trust) и проверка сертификатов

PKI (Public Key Infrastructure, инфраструктура открытых ключей) – это система, обеспечивающая безопасное создание, распределение и проверку цифровых сертификатов. Она лежит в основе доверия в TLS и других криптографических протоколах.

Цепочка доверия — это последовательность сертификатов, связывающая конечный сертификат сервера с корневым центром сертификации (CA). Она включает три уровня:

  1. Корневой сертификат (Root CA)

    1. Самый верхний уровень доверия.

    2. Хранится в доверенных хранилищах ОС (Windows Trusted Root Store, macOS Keychain, Linux ca-certificates) и браузеров.

    3. Срок действия — 10–25 лет.

    4. Если злоумышленник получает доступ к корневому или промежуточному CA, он может подписывать фальшивые сертификаты. Пример: Взлом DigiNotar (2011), когда были выпущены поддельные сертификаты для Google, Facebook.

  2. Промежуточный сертификат (Intermediate CA)

    • Подписан корневым CA, но может подписывать другие сертификаты.

  3. Конечный сертификат (End-Entity Certificate)

    • Выпускается для конкретного домена (например, example.com).

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

Процесс проверки сертификата

Когда клиент (браузер, ОС) получает сертификат сервера, он выполняет 5 шагов верификации:

  1. Проверка срока действия

    • Сертификат должен быть действителен на текущую дату (поля Not Before и Not After).

    • Просроченный сертификат → ошибка NET::ERR_CERT_DATE_INVALID.

  2. Проверка подписи

    • Клиент проверяет, что сертификат подписан доверенным CA. Алгоритм:

      • Извлекает открытый ключ CA из цепочки.

      • Проверяет цифровую подпись сертификата (используя алгоритмы вроде RSA-PSS или ECDSA).

    • NET::ERR_CERT_AUTHORITY_INVALID (неизвестный CA).

  3. Проверка цепочки доверия

    • Клиент строит цепочку от конечного сертификата до корневого:

      example.com → Let's Encrypt R3 (Intermediate) → ISRG Root X1 (Root)

    • Все промежуточные сертификаты должны быть валидны и подписаны.

  4. Проверка отзыва (Revocation Checking)

    • Клиент убеждается, что сертификат не отозван:

      • CRL — скачивает список отозванных сертификатов (редко используется из-за задержек, устравший метод).

      • OCSP — онлайн-проверка статуса сертификата, отправляет запрос к серверу CA (ocsp.digicert.com).

      • OCSP Stapling — сервер сам предоставляет актуальный статус (оптимальный метод).

  5. Проверка имени домена

    • Сертификат должен содержать домен сайта в полях:

      • Common Name (устаревшее).

      • Subject Alternative Name (SAN) — современный стандарт.

    • NET::ERR_CERT_COMMON_NAME_INVALID (например, сертификат для example.org используется на example.com).

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

Тип
Проверка
Использование
Примеры

DV (Domain Validated)

Проверка домена

Базовое шифрование

Let's Encrypt

OV (Organization Validated)

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

Корпоративные сайты

DigiCert OV

EV (Extended Validation)

Глубокая проверка юрлица

Высокий уровень доверия

Банковские сайты

Wildcard

Действует на поддомены

Упрощение управления

*.example.com

SAN (Subject Alternative Name)

Мультидоменный

Несколько доменов в одном серте

example.com, example.net

Снятие шифрования в корпоративной сети (SSL/TLS Inspection)

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

  • Прокси-сервер (или NGFW) выступает как «человек посередине» (MITM):

    1. Клиент соединяется с прокси (например, при запросе к https://example.com).

    2. Прокси подменяет сертификат example.com на свой (корпоративный), подписанный внутренним корневым CA.

    3. Клиент проверяет сертификат прокси — если корпоративный CA доверен в системе, трафик расшифровывается.

    4. Прокси анализирует данные (например, на IDS/IPS, WAF), затем зашифровывает трафик обратно и отправляет на настоящий сервер.

Технические требования:

  • Корпоративный корневой CA должен быть установлен в доверенные хранилища всех устройств в сети.

  • Прокси должен уметь быстро генерировать сертификаты «на лету» (технология Dynamic Certificate Generation).

Зачем WAF сертификат сервера?

WAF (Web Application Firewall) анализирует HTTPS-трафик, поэтому ему нужен доступ к открытому ключу сервера, чтобы его расшифровать.

  • WAF должен проверять HTTP-запросы (например, на наличие SQL-инъекции), но HTTPS по умолчанию зашифрован.

  • WAF использует сертификат сервера (или его закрытый ключ) для дешифрации.

То есть WAF без сертификата сервера не сможет инспектировать HTTPS.

Осторожность с корневыми сертификатами

Установка новых корневых CA в систему или браузер расширяет доверенную зону, что может быть опасно и привести к MITM-атакам:

  • Если злоумышленник добавит свой корневой CA в доверенные, он сможет подписывать любые фальшивые сертификаты (например, для google.com).

Реальные примеры:

  • Superfish (2015): ПО от Lenovo устанавливало собственный корневой CA и подменяло сертификаты, чтобы внедрять рекламу.

  • Компрометация DigiNotar (2011): Хакеры выпустили поддельные сертификаты для Gmail и других сервисов Google.

Как анализировать SSL/TLS трафик на предмет угроз

Несмотря на то, что трафик зашифрован и признаки классических атак в нем обнаружить сложно (да, возможно https://ptsecurity.com/ru-ru/research/analytics/network-traffic-part-2-2020/#id5).

Но есть некоторые вещи, на которые можно еще обратить внимание (помимо TLS-трафика на нестандартнеы порты):

  • Самоподписанные сертификаты в публичном трафике - у таких сертификатов будет совпадать SAN и Issuer, подпись без участия CA. Исключения: Корпоративные сертификаты: Могут быть самоподписанными, но добавлены в доверенные хранилища компании. Тестовые среды: Разработчики часто используют самоподписанные сертификаты для локальных доменов (localhost, *.test).

  • Сертификаты, выпущенные для фишинговых доменов:

    • Стоит коррелировать с информацией whois о времени регистрации домена.

    • Слишком короткий срок действия (1 день).

    • Неизвестные издатели (например, "AdWare CA"). crt.sh — поиск сертификатов по домену.

    • Часто фишинговые домены могут подписываться сертификатом Let's Encrypt, т.к. они бесплатные (это очень косвенный признак).

Само по себе наличие сертификата Let's Encrypt не говорит о том, что сайт плохой. Например, некоторые сайты могут использовать его как второй или временный сертификат, пока идет перевыпуск основного. Например, Let's Encrypt разработали протокол ACME - это стандартный протокол для автоматического выпуска, обновления и отзыва цифровых сертификатов (например, TLS/SSL) без ручного вмешательства. Уменьшает риск просроченных сертификатов (например, из-за забывчивости админов).

openssl – проверка сертификатов

openssl s_client -connect example.com:443 -showcerts # проверка цепочки сертификатов
openssl verify -CAfile chain.pem example.com.crt  # Проверка цепочки
openssl x509 -in cert.pem -text -noout  # Просмотр деталей сертификата
openssl s_client -connect example.com:443 -tls1_2  # Проверка шифров
openssl s_client -connect suspicious.site:443 2>&1 | openssl x509 -noout -issuer -subject # Если issuer = subject — сертификат самоподписанный

JA3/JA3S: Фингерпринтинг TLS-трафика для детектирования угроз

JA3 и JA3S — это методы создания уникальных "отпечатков" (fingerprints) TLS-соединений, позволяющие идентифицировать:

  • JA3 — клиентские приложения (например, Chrome, Malware, IoT-устройства). Формируется на этапе ClientHello.

  • JA3S — серверные приложения (например, Nginx, Apache, C2-серверы). На этапе ServerHello.

Работают на уровне TLS-рукопожатия, анализируя параметры, которые обычно игнорируются традиционными системами мониторинга.

Как формируются отпечатки?

JA3 (Client Fingerprint) формируется из 5 параметров ClientHello:

  1. Версия TLS (например, TLS 1.2 → 769).

  2. Список шифров (Cipher Suites), например: TLS_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 → 4865,4866.

  3. Расширения TLS (например, server_name, extended_master_secret → 0,23).

  4. Эллиптические кривые (Supported Groups): secp256r1, secp384r1 → 23,24.

  5. Форматы точек эллиптических кривых (EC Point Formats): uncompressed → 0.

Формула:

JA3 = TLS_version + "," + Ciphers + "," + Extensions + "," + Curves + "," + Point_Formats

Если в ClientHello нет расширений TLS, поля остаются пустыми

Пример: 769,4865-4866-4867,0-23-65281,23-24,0 → Хешируется в MD5: 6734f37431670b3ab4292b8f60f29984 - это отпечаток JA3

JA3S (Server Fingerprint)

Аналогично, но на основе ServerHello:

  • Версия TLS, выбранный шифр, расширения.

Зачем это нужно SOC?

  • Обнаружение вредоносного ПО: У многих ботов (Emotet, Cobalt Strike) уникальные JA3, отличающиеся от браузеров. RiskIQ JA3 Search — база вредоносных JA3.

  • Выявление C2-серверов: Серверы управления (например, Metasploit) имеют характерные JA3S.

  • Детектирование сканеров: Сканеры Nessus, ZAP имеют свои отпечатки. Certutil имеет свой уникальный отпечаток...

Браузеры рандомизируют JA3, поэтому каждый раз он может быть уникальным.

Что почитать

Previous[Cheat Sheet] Заголовки для защиты сайтаNextКриптография для аналитика SOC

Last updated

Was this helpful?