Информационная безопасность
TLS/SSL и PKI
В 2011 году иранский хакер взломал голландский CA DigiNotar и выпустил поддельные сертификаты Google, Yahoo и Mozilla. Более 300 000 иранцев оказались под MITM-атакой - их зашифрованный трафик читало государство. Проблема была не в слабом шифровании: TLS работал отлично. Проблема была в том, что кто угодно с доступом к CA может притвориться любым сайтом. DigiNotar прекратил существование через несколько недель после взлома.
- **HTTPS везде:** браузер проверяет сертификат при каждом открытии страницы - это TLS handshake, занимающий 1-2 RTT до начала передачи данных
- **mTLS в микросервисах:** Kubernetes service mesh (Istio, Linkerd) автоматически выдает сертификаты каждому поду и требует взаимной аутентификации между сервисами
- **Let's Encrypt:** автоматическая выдача бесплатных сертификатов через ACME-протокол - с 2015 года выдал более 3 млрд сертификатов, сделав HTTPS доступным для всех
TLS Handshake
Каждый раз при открытии банковского сайта между браузером и сервером за долю секунды происходит сложный ритуал - TLS-рукопожатие. Это не просто обмен ключами: это взаимная проверка личности, согласование алгоритмов и установка сессионных ключей, которые никто кроме двух сторон не знает. Протокол TLS 1.3 делает это за один round-trip вместо двух в предыдущих версиях - критично для latency.
TLS 1.3 (RFC 8446, 2018) убрал устаревшие cipher suite, RSA key exchange и сжатие. Минимальный cipher suite: TLS_AES_128_GCM_SHA256. Handshake: ClientHello -> ServerHello+Certificate+Finished -> Client Finished. Всё после ServerHello уже зашифровано.
Какое главное улучшение TLS 1.3 по сравнению с TLS 1.2 в плане производительности?
X.509 Сертификаты
Сертификат X.509 - это цифровой паспорт: содержит публичный ключ владельца, его идентификатор и подпись удостоверяющего центра. Браузер не доверяет ключу напрямую - он доверяет подписи. Именно поэтому сертификат Let's Encrypt стоит 0 долларов, а Comodo EV - 300 долларов в год: разница в уровне проверки личности, а не в криптографии.
Поля сертификата: Subject (кому выдан), Issuer (кто выдал), Validity (срок), Subject Alternative Names (SAN) - список доменов, Public Key, Extensions (KeyUsage, BasicConstraints). С 2017 года Chrome требует SAN вместо CN для проверки домена. Максимальный срок сертификата с 2020 года - 398 дней.
Почему с 2017 года браузеры проверяют поле SAN, а не CN сертификата, при валидации домена?
Цепочка доверия и PKI
В мире около 150 корневых удостоверяющих центров (Root CA), чьи сертификаты предустановлены в браузерах и ОС. Каждый из них может подписать сертификат любого домена в интернете. Это и есть фундаментальная слабость PKI: взлом одного Root CA компрометирует весь интернет. Именно поэтому корневые CA хранятся в Hardware Security Modules в физически защищённых хранилищах и никогда не подписывают сертификаты напрямую.
Цепочка: Root CA (самоподписан, 20-25 лет) -> Intermediate CA (5-10 лет) -> End-entity certificate (1 год). Root CA оффлайн, Intermediate CA онлайн. Certificate Revocation: CRL (списки отзыва) или OCSP (онлайн-проверка). OCSP Stapling - сервер сам прикладывает свежий OCSP-ответ, снижая задержку.
Почему корневые CA хранят свои приватные ключи в оффлайн-хранилищах и не используют их напрямую для подписи сертификатов?
Certificate Pinning
Certificate pinning - это когда приложение отказывается доверять любому CA из системного хранилища и принимает только заранее прошитый сертификат или публичный ключ. Мобильные приложения банков используют pinning именно потому, что корпоративные прокси и антивирусы перехватывают HTTPS-трафик подменяя сертификат. Пин убивает любой Man-in-the-Middle, даже легитимный.
Public Key Pinning (HPKP) в HTTP-заголовках был признан опасным и удален из браузеров: неверный пин = недоступный сайт навсегда. Альтернативы: Certificate Transparency (CT) - публичные логи всех выданных сертификатов, Expect-CT заголовок. Для мобильных приложений пиннинг по SHA-256 хешу SubjectPublicKeyInfo - стандартная практика.
TLS шифрует данные - значит никто не может их перехватить
TLS защищает канал, но не защищает от компрометации конечных точек или подмены CA
Корпоративные прокси, антивирусы и государственные MITM-системы устанавливают свой CA в хранилище ОС и перехватывают весь TLS-трафик. Шифрование есть, но ключи - у посредника. Pinning и Certificate Transparency помогают обнаружить такой перехват.
Почему HTTP Public Key Pinning (HPKP) через заголовки был признан опасным и удален из браузеров?
Ключевые идеи
- **TLS 1.3** - один round-trip для handshake, Perfect Forward Secrecy обязателен, устаревшие алгоритмы удалены
- **Сертификат X.509** - цифровой паспорт с публичным ключом и подписью CA; SAN обязателен для валидации домена с 2017 года
- **Цепочка доверия** - Root CA оффлайн, Intermediate CA онлайн; компрометация одного CA не убивает всю систему
- **Certificate Pinning** - жесткая привязка к конкретному ключу защищает от MITM даже через легитимные CA, но требует осторожного обновления
Связанные темы
TLS/PKI - фундамент для целого пласта протоколов и практик безопасности:
- Криптография (симметричная и асимметричная) — TLS использует асимметричную криптографию в handshake и симметричную для передачи данных
- Сетевая безопасность — TLS защищает транспортный уровень; firewall и IDS работают на сетевом уровне
Вопросы для размышления
- Если Let's Encrypt бесплатно выдает сертификаты любому, что мешает злоумышленнику получить валидный сертификат для фишингового сайта evil-paypa1.com?
- Как организовать обновление сертификатов в мобильном приложении с certificate pinning без того, чтобы пользователи со старой версией приложения потеряли доступ к API?
- В чём принципиальная разница между TLS и SSH с точки зрения модели доверия?