Как работает SSL/TLS: TLS-рукопожатие в деталях

Каждый раз, когда вы посещаете HTTPS-сайт, ваш браузер и сервер выполняют TLS-рукопожатие — быстрый обмен, который аутентифицирует сервер, согласовывает параметры шифрования и вырабатывает общий секретный ключ. Это происходит за 1-2 сетевых обмена (50-200 мс), прежде чем загрузится какой-либо контент страницы.

TLS 1.3 рукопожатие (текущий стандарт)

TLS 1.3 завершает рукопожатие за один обмен (1-RTT):

Шаг 1 — Client Hello Ваш браузер отправляет: поддерживаемые версии TLS, поддерживаемые наборы шифров, случайное число и параметры обмена ключами (для протокола Диффи — Хеллмана).

Шаг 2 — Server Hello + Certificate + Finished Сервер отвечает: выбранный набор шифров, свой сертификат (подтверждающий его личность), свою долю ключа и сообщение “Finished”. В TLS 1.3 сертификат зашифрован — пассивные наблюдатели не могут видеть, к какому сайту вы подключаетесь.

Шаг 3 — Client Finished Браузер проверяет сертификат по своему списку доверенных CA, вычисляет общий сеансовый ключ на основе обмена Диффи — Хеллмана и отправляет своё сообщение “Finished”. Зашифрованные данные приложения теперь могут передаваться.

Итого: 1 обмен. Возобновлённые соединения (когда клиент уже подключался ранее) могут использовать 0-RTT — отправляя зашифрованные данные уже с первым сообщением.

TLS 1.2 рукопожатие (всё ещё широко используется)

TLS 1.2 требует 2 обмена:

1. Client Hello → поддерживаемые версии, шифры, случайное число
2. Server Hello → выбранный шифр, сертификат, обмен ключами сервера
3. Client Key Exchange → предварительный секрет (зашифрованный открытым ключом сервера или через Диффи — Хеллмана)
4. Change Cipher Spec + Finished (обе стороны)

TLS 1.2 поддерживает больше наборов шифров — включая некоторые слабые. Правильная конфигурация важнее, чем в случае TLS 1.3.

Что происходит внутри зашифрованного соединения

После рукопожатия все данные шифруются согласованным сеансовым ключом с использованием симметричного шифра (обычно AES-256-GCM или ChaCha20-Poly1305):

• Конфиденциальность — данные зашифрованы; только две конечные точки могут их прочитать
• Целостность — каждое сообщение включает MAC (код аутентификации сообщения); любое вмешательство обнаруживается
• Аутентификация — сертификат сервера подтверждает его личность (и, опционально, личность клиента)

Каждый HTTP-запрос и ответ — заголовки, тело, куки, URL — передаётся через этот зашифрованный канал.

Прямая секретность

Современный TLS использует эфемерный обмен ключами Диффи — Хеллмана, что означает: каждое соединение генерирует уникальный сеансовый ключ. Даже если закрытый ключ сервера будет скомпрометирован позже, прошлые разговоры не могут быть расшифрованы.

TLS 1.3 делает прямую секретность обязательной. TLS 1.2 поддерживает её, но также допускает обмен ключами RSA (который не обеспечивает прямую секретность). Вот почему предпочтителен TLS 1.3.

Роль сертификата

TLS-рукопожатие зависит от наличия у сервера действующего SSL/TLS-сертификата. Сертификат предоставляет:

1. Открытый ключ сервера — используется при обмене ключами
2. Доменное имя (имена) — браузер проверяет их соответствие URL
3. Подпись CA — доказывает, что доверенный центр сертификации поручается за этот сертификат
4. Даты действия — браузер отклоняет просроченные сертификаты

Без действующего сертификата рукопожатие терпит неудачу и браузер показывает предупреждение безопасности. Получить бесплатный сертификат →

Производительность

На современном оборудовании вычислительные затраты на шифрование пренебрежимо малы — инструкции AES-NI обрабатывают его аппаратно. Основная стоимость — дополнительный(ые) обмен(ы), которые TLS 1.3 минимизирует.

Что видно в сети

Без HTTPS (HTTP)

Наблюдатель в сети видит всё:

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

Имена пользователей, пароли, куки, содержимое страниц — всё в открытом виде.

С HTTPS (TLS)

Тот же наблюдатель видит:

[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]

Они могут видеть IP-адрес назначения и имя хоста SNI (в TLS 1.2 — зашифровано в TLS 1.3 с ECH). Они не могут видеть путь URL, заголовки, тело или куки.

Как сертификат вписывается в процесс

TLS-рукопожатие зависит от наличия у сервера действующего SSL/TLS-сертификата:

1. Открытый ключ сервера — используется при обмене ключами
2. Доменное имя (имена) — браузер проверяет их соответствие URL
3. Подпись CA — доказывает, что доверенный центр сертификации поручается за этот сертификат
4. Даты действия — браузер отклоняет просроченные сертификаты

Без действующего сертификата рукопожатие терпит неудачу и браузер показывает предупреждение безопасности. Получить бесплатный сертификат →

Распространённые наборы шифров TLS в 2026 году

TLS 1.3 (только 5 наборов шифров — все безопасные)

TLS_AES_256_GCM_SHA384       ← Most common
TLS_AES_128_GCM_SHA256       ← Widely used
TLS_CHACHA20_POLY1305_SHA256 ← Best for mobile/ARM
TLS_AES_128_CCM_SHA256       ← IoT/embedded
TLS_AES_128_CCM_8_SHA256     ← IoT/embedded (short tag)

TLS 1.2 (используйте только AEAD-наборы)

ECDHE-ECDSA-AES256-GCM-SHA384  ← Best with ECC cert
ECDHE-RSA-AES256-GCM-SHA384    ← Best with RSA cert
ECDHE-ECDSA-CHACHA20-POLY1305  ← Mobile-optimized

Избегайте не-AEAD наборов (режим CBC) в TLS 1.2 — они были уязвимы к атакам вроде BEAST и Lucky13.

Часто задаваемые вопросы

HTTPS замедляет мой сайт?

TLS-рукопожатие добавляет один обмен (TLS 1.3) или два (TLS 1.2) при первом соединении. Возобновление сеанса устраняет это для повторных посетителей. Поскольку HTTPS включает HTTP/2 (мультиплексирование, сжатие заголовков), HTTPS-сайты часто работают быстрее в целом.

Что такое набор шифров?

Набор шифров — это комбинация алгоритмов, используемых для обмена ключами, шифрования и аутентификации сообщений. Пример: TLS_AES_256_GCM_SHA384 означает TLS с шифрованием AES-256-GCM и SHA-384 для целостности сообщений. TLS 1.3 имеет всего 5 наборов шифров — все безопасные. TLS 1.2 имеет 37, некоторые из которых слабые.

Может ли кто-то расшифровать HTTPS-трафик позже?

Не при наличии прямой секретности (эфемерный обмен ключами). Каждый сеанс использует уникальный ключ, выведенный из обмена Диффи — Хеллмана. Даже при компрометации долгосрочного закрытого ключа сервера прошлые сеансовые ключи не могут быть восстановлены. TLS 1.3 обеспечивает это принудительно; TLS 1.2 поддерживает при правильной конфигурации.

Какое отношение имеет GetHTTPS к этому?

GetHTTPS генерирует сертификат, который делает TLS-рукопожатие возможным. Сертификат содержит открытый ключ, который сервер использует при обмене ключами. GetHTTPS создаёт эту пару ключей в вашем браузере с помощью Web Crypto API и напрямую подключается к ACME API Let’s Encrypt для получения подписи. Как работает GetHTTPS →