TLS и PKI

Что TLS на самом деле обязан сделать

У TLS две задачи, которые постоянно путают: конфиденциальность (никто на проводе не прочитает байты) и аутентификация (вы действительно говорите с payments.example.com, а не с самозванцем посередине). Одно шифрование без второго бесполезно — атакующий, который перехватывает трафик, с тем же успехом поднимет свой зашифрованный туннель к вам, читая всё насквозь. Весь смысл сертификатной машинерии — привязать ключи шифрования к проверенной личности, чтобы канал был и приватным, и доказуемо к нужной стороне.

TLS 1.3 (RFC 8446) — это намеренный сброс протокола. Он удалил опасные части TLS 1.2 — статический обмен ключами RSA, шифры в режиме CBC, RC4, сжатие, renegotiation — и оставил только конструкции с forward secrecy и AEAD. Практических следствий два: рукопожатие быстрее (один round trip вместо двух для нового соединения и опциональный zero round trip для возобновления), и множество способов всё неправильно настроить резко сократилось. Не осталось рычага «откатиться на экспортную крипту», который можно повернуть не туда.

Рукопожатие 1.3 за один round trip

Вот последовательность для свежего соединения. Клиент открывает ClientHello, который уже содержит key share — эфемерное публичное значение Диффи-Хеллмана — для кривых, которые сервер, по его догадке, примет. Эта догадка и есть приём, схлопывающий два round trip в один: клиент не ждёт, пока ему скажут, какие параметры использовать, — он спекулирует.

Сервер отвечает ServerHello со своим key share. В этот миг обе стороны могут вычислить общий секрет через Диффи-Хеллмана и вывести симметричные ключи рукопожатия — поэтому всё, что сервер шлёт дальше, уже зашифровано, включая сертификат. Затем идёт часть, которая собственно кого-то аутентифицирует:

• Certificate: листовой сертификат сервера плюс промежуточные, нужные для построения цепочки.
• CertificateVerify: подпись, сделанная приватным ключом сертификата, над транскриптом всего рукопожатия до этого момента. Это шаг, доказывающий, что сервер владеет приватным ключом, соответствующим публичному ключу в сертификате, — а не просто скопировал чужой файл сертификата.
• Finished: MAC над транскриптом, запирающий рукопожатие от подмены.

Клиент проверяет цепочку и подпись CertificateVerify, шлёт свой Finished, и идут данные приложения. Один round trip из конца в конец.

Сертификаты, цепочки и CA

Сертификат — это подписанное утверждение: «этот публичный ключ принадлежит этому имени, и я, издатель, ручаюсь за это до этой даты истечения». Имя живёт в поле Subject Alternative Name (SAN) (старый Common Name современные клиенты игнорируют). Критично: листовому сертификату сервера не доверяют напрямую. Он подписан промежуточным CA, который подписан корневым CA. Эта последовательность — лист → промежуточный → корень — и есть цепочка сертификатов.

Причина этого слоя косвенности операционная, а не криптографическая. Приватные ключи корневых CA хранят офлайн в аппаратных модулях безопасности (HSM) и почти никогда не трогают, потому что утечка корневого ключа обесценивает все сертификаты, что он когда-либо закреплял, и его нельзя тихо заменить — он зашит в миллиарды устройств. Промежуточные делают повседневную подпись и могут быть отозваны и ротированы без апокалипсиса. Сервер обязан слать свой лист и промежуточные; сервер, отдающий только лист, выдаёт классическую ошибку «цепочка не доверена» на клиентах, у которых этот промежуточный не закэширован.

Как браузер решает, что сертификат валиден

Вот часть, которую инженеры чаще всего отмахивают. Когда приходит лист, клиент прогоняет цепочку проверок, и все они должны пройти — провал любой одной и вызывает страшное полноэкранное предупреждение:

1. Построить цепочку к доверенному якорю. Клиент идёт лист → промежуточный → корень и подтверждает, что корень есть в его trust store — предустановленном списке корневых CA операционной системы или браузера, которым решено доверять априори. Доверие не магия; оно упирается в этот выверенный список из нескольких сотен корней. Если цепочка не оканчивается на одном из них — сертификат не доверен, точка.
2. Проверить каждую подпись вверх по цепочке. Подпись каждого сертификата должна валидироваться против публичного ключа следующего сертификата. Разрыв где угодно означает, что цепочка подделана или неполна.
3. Проверить даты валидности. Каждый сертификат в цепочке должен быть в своём окне notBefore/notAfter. Это и есть пейджер в 03:00 про истёкший сертификат.
4. Проверить имя. Имя хоста, которое запросил клиент, должно совпасть с записью SAN на листе. Подключение к payments.example.com и получение сертификата для example.com без совпадающего SAN — провал; именно это останавливает атакующего, предъявляющего валидный сертификат для домена, которым он владеет.
5. Проверить отзыв. Не отозвал ли CA этот сертификат досрочно (компрометация ключа, ошибочная выдача)? Проверяется через CRL или, чаще, OCSP / OCSP stapling, когда сервер прикладывает свежее подписанное доказательство «всё ещё годен», чтобы клиенту не звонить CA.