Транспорт бэкенда
DNS и TLS: адресация и безопасность
2013 год. Эдвард Сноуден публикует документы АНБ. Один из шокирующих фактов: трафик между датацентрами Google - незашифрован и перехватывается. Google, зная это, за 10 месяцев шифрует все internal каналы через TLS. В 2014 Google начинает учитывать HTTPS как фактор ранжирования. В 2018 Chrome помечает все HTTP сайты как 'Not Secure'. Сегодня 95%+ трафика в Chrome - HTTPS. Один инцидент изменил приоритеты безопасности всей индустрии.
- **Cloudflare** обрабатывает миллиарды DNS запросов в день через 1.1.1.1 - самый быстрый публичный resolver (среднее время < 11ms)
- **Let's Encrypt** выдала 3+ миллиарда сертификатов - сделала HTTPS доступным для любого сайта бесплатно
- **Istio** в Kubernetes автоматически устанавливает mTLS между всеми pods - zero-trust networking без изменения кода
Paul Mockapetris и изобретение DNS
До 1983 года интернет использовал единый файл HOSTS.TXT, поддерживаемый вручную в Stanford Research Institute. При 300 хостах обновление занимало недели, файл постоянно устаревал. Paul Mockapetris разработал DNS (RFC 882, 883, затем 1034/1035 в 1987) - иерархическую распределённую систему. Идея: делегирование ответственности за зоны. Сегодня DNS обрабатывает 400+ миллиардов запросов в день для 350+ миллионов доменов. TLS разработал Taher Elgamal в Netscape в 1994 как SSL, стандартизирован IETF как TLS 1.0 в 1999. Netcraft: SSL/TLS - самый влиятельный криптографический протокол в истории интернета.
DNS Resolution
**DNS (Domain Name System)** - иерархическая распределённая база данных, преобразующая доменные имена в IP-адреса. Без DNS каждый запрос к `api.github.com` требовал бы знания IP-адреса. DNS - аналог телефонной книги интернета, но распределённой и кэшированной на миллионах серверов.
**DNS TTL и кэширование**: TTL (Time To Live) определяет сколько секунд кэшировать запись. GitHub: TTL=60s (быстрое переключение при failover). Большинство сайтов: TTL=300-3600s. Проблема: при смене IP DNS не мгновенно обновляется - нужно ждать TTL. Перед плановой сменой IP понижай TTL до 60s за сутки до изменения.
DNS запись A для api.example.com изменена на новый IP. TTL = 3600 секунд. Через сколько времени все клиенты увидят новый IP?
TLS Handshake
**TLS (Transport Layer Security)** - криптографический протокол поверх TCP, обеспечивающий confidentiality (шифрование), integrity (защита от модификации) и authentication (проверка что сервер тот кем называется). HTTPS = HTTP over TLS. TLS 1.3 (2018) - текущий стандарт: быстрее, безопаснее TLS 1.2.
**Forward Secrecy**: в TLS 1.3 каждое соединение использует ephemeral ключи (новые для каждого handshake). Даже если private key сервера скомпрометирован в будущем - прошлые записанные сессии не дешифрованы. TLS 1.2 без DHE/ECDHE - не имеет forward secrecy.
TLS 1.3 завершает handshake за 1-RTT, TLS 1.2 за 2-RTT. Что ускорило TLS 1.3?
Certificates и PKI
**X.509 сертификат** - цифровой документ, связывающий публичный ключ с идентификатором (доменным именем). Подписан Certificate Authority (CA) - доверенной третьей стороной. PKI (Public Key Infrastructure) - иерархия доверия: Root CA → Intermediate CA → End-entity certificate.
| Тип | Проверяет | Стоимость | Когда использовать |
|---|---|---|---|
| DV (Domain Validation) | Контроль над доменом | Бесплатно (Let's Encrypt) | API, личные проекты, большинство сайтов |
| OV (Organization Validation) | Домен + организация | $50-300/год | Корпоративные сайты |
| EV (Extended Validation) | Расширенная верификация организации | $100-500/год | Банки, e-commerce (зелёный замок в старых браузерах) |
| Wildcard (*.example.com) | Все поддомены | $100+/год или Certbot | Много поддоменов: api.*, admin.* |
| SAN (Multi-domain) | Несколько доменов | Включено в Certbot | example.com + www.example.com + api.example.com |
**Certificate pinning** - хранение конкретного public key в приложении и отказ от соединений с другими сертификатами. Защищает от компрометации CA, но блокирует rotation сертификата. Facebook/Google используют в mobile apps. Для API backends - предпочесть certificate transparency monitoring.
Let's Encrypt сертификат истёк. Что произойдёт при HTTPS-запросе к сайту?
mTLS: взаимная аутентификация
**mTLS (mutual TLS)** - расширение TLS где обе стороны (клиент и сервер) предъявляют сертификаты. В обычном TLS только сервер аутентифицируется. В mTLS клиент также доказывает свою идентичность сертификатом. Стандарт для service-to-service аутентификации в микросервисах.
| Сценарий | Обычный TLS | mTLS |
|---|---|---|
| Браузер → Веб-сайт | Подходит (сервер аутентифицируется) | Избыточно |
| Микросервис A → Микросервис B | Недостаточно (кто клиент?) | Обязательно |
| API Gateway → Backend | Зависит от требований | Best practice |
| Устройства IoT → Cloud | Рискованно | Стандарт (device certificates) |
| Service Mesh (Istio/Linkerd) | N/A | Автоматический mTLS между pods |
**Service Mesh и mTLS**: Istio и Linkerd автоматически выдают сертификаты всем pods и устанавливают mTLS между сервисами без изменения кода. Certificate rotation - автоматически каждые 24 часа. Zero-trust network model: каждый сервис доказывает идентичность при каждом соединении.
mTLS сложен в настройке и подходит только для enterprise
Istio и Linkerd автоматизируют mTLS для всех pods в кластере без изменения кода приложений. Включается одной аннотацией или глобальной политикой.
Ручная настройка mTLS (создание CA, выдача сертификатов, rotation) действительно сложна. Service mesh абстрагирует это: sidecar proxy прозрачно устанавливает mTLS между сервисами. Certmanager в Kubernetes автоматизирует certificate lifecycle.
Микросервис Payment-Service вызывает Fraud-Detection-Service по HTTPS. Обычного TLS достаточно для безопасности?
Ключевые идеи
- **DNS** - иерархическая система: Browser → Recursive Resolver → Root → TLD → Authoritative. TTL контролирует propagation скорость
- **TLS 1.3**: 1-RTT handshake, обязательный forward secrecy (ephemeral ECDH keys), убраны уязвимые алгоритмы
- **Сертификаты**: X.509, chain of trust через CA. Let's Encrypt = бесплатные DV сертификаты с ACME автообновлением
- **mTLS**: обе стороны аутентифицируются сертификатами. Обязателен для service-to-service. Service mesh (Istio) автоматизирует
Вопросы для размышления
- Компания переходит на микросервисную архитектуру: 50 сервисов в Kubernetes. Нужна service-to-service аутентификация. Сравни два подхода: (1) каждый сервис проверяет JWT токен в заголовке, (2) Istio с автоматическим mTLS. Какой выбрать и почему?