RFC
TLS 1.3 (RFC 8446)
Базовый стандарт современного TLS handshake и key schedule.
Когда мы говорим про безопасность канала и доверие между сервисами, почти всегда за кулисами работают три слоя: криптографические примитивы, инфраструктура ключей и протокол транспорта. На практике это выглядит как связка асимметрии + PKI + TLS, а не как один «магический» алгоритм.
Что важно понимать про шифрование
Asymmetric Encryption
- Пара ключей: public key можно распространять, private key должен оставаться секретным.
- Шифрование обычно делают гибридно: данные шифруют симметричным ключом, а ключ - через public key.
- Основная практическая роль: безопасный обмен ключами и bootstrap доверия.
Digital Signatures
- Подпись подтверждает целостность и источник данных (authenticity + integrity).
- Sign: private key, Verify: public key.
- В TLS подписи используются для доказательства владения серверным ключом.
Key Management
- Реальная безопасность зависит от lifecycle ключей: генерация, хранение, ротация, отзыв.
- KMS/HSM, key versioning, access policies и audit trail - базовый production минимум.
- Компрометация private key часто опаснее, чем баг в самом протоколе.
PKI
X.509 / RFC 5280
Стандарт сертификатов и базовых правил certificate chain validation.
Инфраструктура открытых и закрытых ключей (PKI)
Root CA
Якорь доверия. Обычно офлайн, с жестким контролем доступа.
Intermediate CA
Подписывает серверные сертификаты, изолируя риск от root ключа.
Leaf Certificate
Сертификат конкретного домена/сервиса с public key и сроком действия.
Revocation / Rotation
CRL/OCSP, короткие TTL сертификатов и регулярная ротация ключей.
Production-подход: private keys должны храниться в KMS/HSM с минимальными правами доступа, регулярной ротацией и обязательным аудитом операций с ключами.
Как работает TLS 1.3 (упрощенно)
До завершения handshake стороны договариваются о параметрах и ключах, после Finished приложение работает через защищённый канал.
Нажмите Start визуализации, чтобы пройти TLS 1.3 handshake по шагам.
TLS 1.3 убрал устаревшие механизмы и ускорил handshake при сохранении security guarantees.
Даже идеальный TLS не решает бизнес-авторизацию: AuthZ должен быть отдельным слоем.
Типичные ошибки
- Считать, что 'HTTPS включен' автоматически закрывает все риски: TLS закрывает канал, но не заменяет AuthN/AuthZ.
- Длинноживущие сертификаты и ключи без ротации.
- Игнорирование проверки certificate chain и hostname.
- Хранение private keys в plain text на хостах без KMS/HSM и контроля доступа.
- Одинаковые ключи для разных сред (dev/stage/prod).
- Отсутствие мониторинга expiry и процедур аварийного key revoke.