CS Notes

tls

3 min read

TLS

Предпосылки: TCP (соединение, рукопожатие).

← HTTP | Эволюция HTTP →

HTTP передаёт данные открытым текстом. Когда пользователь вводит пароль на сайте, этот пароль проходит через десятки роутеров, каждый из которых может прочитать содержимое. Провайдер, оператор Wi-Fi в кафе, любой узел на пути — все видят данные как есть.

HTTPS = HTTP + TLS

HTTPS — HTTP поверх TLS (Transport Layer Security — безопасность транспортного уровня). TLS — криптографический протокол, который оборачивает TCP-соединение в защитный слой, обеспечивая три свойства.

Шифрование — данные нечитаемы для перехватчика. Промежуточные узлы видят только зашифрованный поток байтов. Аутентификация — подтверждение подлинности сервера. Клиент уверен, что подключился к настоящему google.com, а не к подставному серверу. Целостность — данные нельзя незаметно изменить в пути.

Ключи и роли

Для понимания TLS важно разделять две задачи: кто перед нами и каким ключом шифровать основной трафик.

Асимметричная криптография использует пару ключей: публичный и приватный. В TLS она нужна в первую очередь для аутентификации: сертификат связывает публичный ключ с доменным именем, а сервер доказывает, что владеет соответствующим приватным ключом. Эти операции сравнительно дорогие.

Симметричное шифрование использует один общий секретный ключ. Им уже шифруется весь основной поток данных, потому что оно намного быстрее.

Важно не упростить модель слишком сильно: современный TLS обычно не “шифрует сессионный ключ публичным ключом сервера”. В TLS 1.3 стороны обычно выводят общий секрет через одноразовый Diffie-Hellman обмен, а сертификат нужен, чтобы убедиться, что этот обмен действительно идёт с правильным сервером.

TLS-рукопожатие

TLS-рукопожатие происходит после установки TCP-соединения, но до первого HTTP-запроса:

  1. ClientHello — клиент сообщает поддерживаемые версии TLS, наборы алгоритмов и обычно сразу отправляет свою одноразовую открытую часть Diffie-Hellman обмена.
  2. ServerHello — сервер выбирает параметры и отправляет свою открытую часть обмена. Уже на этом шаге обе стороны могут вычислить общий секрет.
  3. Сертификат сервера — сервер отправляет цепочку сертификатов. Клиент проверяет: домен совпадает? цепочка подписи ведёт к доверенному CA? сроки действия не истекли?
  4. Доказательство владения ключом — сервер подписывает часть рукопожатия своим приватным ключом. Это связывает вычисленный секрет с конкретной идентичностью сервера.
  5. Finished — стороны подтверждают, что одинаково видят ход рукопожатия и вывели одинаковые ключи.
  6. Защищённое соединение — после этого HTTP-данные шифруются уже симметрическими ключами сессии.

Сертификаты и цепочка доверия

Сертификат — электронный документ: “это действительно example.com, публичный ключ такой-то, подписано удостоверяющим центром X”. CA (Certificate Authority — удостоверяющий центр) — организация, которой доверяют браузеры и операционные системы. CA проверяет, что заявитель действительно владеет доменом, и подписывает сертификат своим приватным ключом.

Доверие выстраивается в цепочку: браузер доверяет корневым CA (их сертификаты предустановлены в ОС), корневой CA подписывает промежуточный CA, промежуточный CA подписывает сертификат сайта. Клиент проверяет всю цепочку от сертификата сайта до корневого CA.

Бесплатные сертификаты выдаёт Let’s Encrypt — CA, который автоматически проверяет владение доменом через HTTP-челлендж или DNS-запись.

Влияние на производительность

TLS добавляет латентность: помимо TCP-рукопожатия нужно ещё криптографическое согласование ключей. Для нового соединения полный TLS 1.2 handshake обычно добавляет 2 RTT поверх TCP, TLS 1.3 — 1 RTT. При возобновлении сессии TLS 1.3 поддерживает 0-RTT: клиент может отправить часть данных сразу, но цена — более слабые гарантии для этих ранних данных, прежде всего риск их повторного воспроизведения. Поэтому 0-RTT используют только там, где повтор запроса безопасен.

TLS решает проблему безопасности на уровне одного соединения. Эволюция самого HTTP — от одного запроса на соединение до мультиплексирования — описана в эволюции HTTP.

Sources

← HTTP | Эволюция HTTP →

Graph View

Backlinks