Как работает TLS? Расскажите про рукопожатие, цепочку сертификатов и чем симметричное шифрование отличается от асимметричного.
Короткий ответ
- Асимметричная криптография — для обмена ключами и подписей
- Симметричная — для шифрования самого трафика, она быстрее
- Рукопожатие TLS 1.3: согласование шифров и обмен ключами за один round-trip
- Сервер предъявляет сертификат, подписанный центром сертификации
- Клиент проверяет цепочку до доверенного корня, срок и имя хоста
- Автоматизация выпуска: ACME и Let's Encrypt, cert-manager в Kubernetes
TLS соединяет асимметрию для доверия и обмена ключами с симметрией для скорости шифрования данных.
Как сказать вслух
пример ответаПри установке TLS-соединения клиент и сервер договариваются о версии протокола и шифрах, сервер предъявляет сертификат, а через алгоритм Диффи-Хеллмана стороны получают общий сеансовый ключ. Дальше весь трафик шифруется симметрично, потому что это намного быстрее. Клиент проверяет, что сертификат подписан доверенным центром, не истёк и выписан на нужное имя. В работе я автоматизирую выпуск сертификатов, чтобы исключить инциденты с протуханием.
Подробный ответ
Основной ответ
В TLS 1.3 клиент в ClientHello сразу отправляет поддерживаемые шифры и свой ключевой материал для ECDHE; сервер отвечает ServerHello, сертификатом и подтверждением — рукопожатие укладывается в один round-trip. Асимметричная криптография решает две задачи: подпись сертификата центром сертификации (доверие) и обмен ключами с прямой секретностью (ephemeral Diffie-Hellman). Дальше работает симметричный шифр (AES-GCM, ChaCha20-Poly1305). Клиент валидирует цепочку: серверный сертификат → промежуточный CA → корневой CA из хранилища доверия, плюс срок действия и соответствие SAN имени хоста. Типовые проблемы: не отдан промежуточный сертификат, истёкший срок, несовпадение имени. Выпуск автоматизируют через ACME (Let's Encrypt, cert-manager).
Ключевые моменты
- Гибридная схема. Асимметрия — дорогая, используется только для установления доверия и общего ключа; данные шифруются симметрично.
- Цепочка доверия. Сервер обязан отдавать промежуточные сертификаты; их отсутствие — классическая причина ошибок у части клиентов.
- Perfect Forward Secrecy. Эфемерные ключи ECDHE означают, что компрометация приватного ключа сервера не раскрывает прошлый трафик.
- Эксплуатация. Мониторинг сроков сертификатов и автопродление — обязательны; истёкший сертификат — до сих пор частая причина инцидентов.
Практический контекст
Инженер постоянно сталкивается с TLS: терминация на балансировщике или Ingress, mTLS между сервисами, отладка ошибок вида «certificate verify failed». Интервьюер смотрит, понимает ли кандидат разницу между шифрованием и аутентификацией и сможет ли отладить проблему через openssl s_client или curl -v, а не просто пересоздать сертификат наугад.
Частые ошибки
- Говорят, что весь трафик шифруется асимметрично публичным ключом сервера
- Не знают про промежуточные сертификаты и проверку цепочки
- Не упоминают проверку имени хоста (SAN) при валидации