Цифровые подписи, сертификаты и TLS

Предыдущий урок оставил один вопрос открытым: асимметричное шифрование позволяет отправить секрет тому, чей открытый ключ у вас есть, — но откуда вам знать, что этот открытый ключ действительно принадлежит именно ему, а не злоумышленнику посередине? На этот вопрос отвечают цифровые подписи и сертификаты, и вместе они делают возможным TLS — протокол, стоящий за каждым адресом https://.

Цифровые подписи: доказательство происхождения, а не секретности

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

Сертификаты: подпись, ручающаяся за открытый ключ

Цифровой сертификат решает проблему «чей это на самом деле открытый ключ». Как поясняет Learning Center компании Cloudflare, сертификат SSL/TLS — это «файл данных, размещённый на исходном сервере веб-сайта», содержащий доменное имя, открытый ключ, срок действия и — что критично — «цифровую подпись удостоверяющего центра». Удостоверяющий центр (CA) — доверенная третья сторона, которая проверяет, что сайт контролирует домен, для которого запрашивается сертификат, а затем подписывает этот сертификат собственным закрытым ключом. Ваш браузер поставляется со встроенным списком удостоверяющих центров, которым он доверяет, поэтому, получив сертификат, подписанный одним из них, он может доверять содержащемуся в нём открытому ключу, ни разу не встретившись с оператором сайта. Самоподписанный сертификат — тот, который сайт подписывает сам, а не получает от CA, — не имеет такого внешнего поручительства, поэтому браузеры по умолчанию считают его ненадёжным.

TLS: как оба инструмента работают вместе

RFC 8446, спецификация TLS 1.3, описывает рукопожатие как последовательность этапов: обмен ключами, на котором обе стороны устанавливают общий секретный материал; затем аутентификация, на которой, по словам самого RFC, «серверная сторона канала аутентифицируется всегда; клиентская сторона аутентифицируется опционально» — обычно личность подтверждает только сайт, а не посетитель. Сервер доказывает, кем он является, с помощью своего сертификата и подписи, которую мог создать только он, обладая закрытым ключом. Как только обе стороны доверяют соединению, они получают быстрые симметричные ключи (обычно AES из предыдущего урока) для самих данных. RFC 8446 прямо заявляет, что это даёт: конфиденциальность и целостность обмениваемых данных, а также аутентификацию сервера. Он так же прямо указывает и на ограничение: «TLS не скрывает длину передаваемых данных», а такие метаданные, как то, к какому серверу вы подключились и когда, остаются видимыми для любого, кто способен наблюдать за соединением.

Что означает и чего не означает значок замка

Фишинговый сайт на домене-двойнике может иметь совершенно действительный сертификат: TLS подтверждает подлинность домена, а не намерения того, кто его зарегистрировал. Именно поэтому более ранний урок о том, как разворачиваются атаки, рассматривает поддельную страницу входа, замок и всё прочее, как реальную угрозу, а не как противоречие.