Как на самом деле работают HTTPS и TLS: под капотом

Security2026-11-08TryQuickToolBox

Вы вводите URL, нажимаете Enter и видите замок. Но что на самом деле происходит между вашим браузером и сервером, чтобы это соединение стало безопасным? Многие разработчики воспринимают HTTPS как чёрный ящик — пока что-то не сломается, например, ошибка сертификата или проблема с производительностью. Эта статья приоткрывает завесу над HTTPS и TLS, объясняя рукопожатие, шифрование и проверку сертификатов на практических примерах.

Что такое HTTPS на самом деле

HTTPS — это просто HTTP, работающий поверх TLS (Transport Layer Security). TLS обеспечивает три гарантии:

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

TLS произошёл от SSL (Secure Sockets Layer). Современные версии (TLS 1.2 и 1.3) — это то, что следует использовать; SSL устарел.

Рукопожатие TLS: шаг за шагом

Прежде чем пойдут какие-либо HTTP-данные, клиент и сервер выполняют рукопожатие, чтобы согласовать ключи шифрования. Вот что происходит в типичном рукопожатии TLS 1.3 (упрощённо):

Client Hello: Браузер отправляет список поддерживаемых наборов шифров, случайное значение и свой ключевой обмен для обмена ключами.
Server Hello: Сервер выбирает набор шифров, отправляет своё случайное значение и ключевой обмен, а также предъявляет свой сертификат.
Выработка ключей: Обе стороны вычисляют общий секрет с помощью обмена ключами Диффи-Хеллмана. Из него они выводят сеансовые ключи для симметричного шифрования.
Finished: Обе стороны отправляют MAC (код аутентификации сообщения) для проверки целостности рукопожатия. Теперь может передаваться зашифрованные данные приложения.

TLS 1.3 сократил рукопожатие до одного кругового обхода (1-RTT) и даже поддерживает 0-RTT для возобновлённых сессий, улучшая задержку.

Обмен ключами: Диффи-Хеллман

Магия современного TLS в том, что клиент и сервер могут согласовать общий секрет, никогда не передавая его. Диффи-Хеллман (конкретно ECDHE для эллиптических кривых) позволяет это. Даже если злоумышленник запишет всё рукопожатие, он не сможет вывести сеансовый ключ — это свойство называется прямая секретность (forward secrecy).

Симметричное шифрование: AES или ChaCha20

Как только общий секрет установлен, TLS переключается на симметричное шифрование (например, AES-GCM или ChaCha20-Poly1305), потому что оно намного быстрее асимметричной криптографии. Сеансовые ключи используются для шифрования всех данных приложения.

Проверка сертификата: доверяй, но проверяй

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

Цепочка доверия: Сертификат должен выстраиваться в цепочку до доверенного корневого CA, предустановленного в браузере или ОС.
Соответствие имени хоста: Сертификат должен быть действителен для домена, который вы посещаете (через Subject Alternative Names).
Срок действия: Сертификат не должен быть просроченным или ещё не вступившим в силу.
Отзыв: Браузер может проверить OCSP или CRL, чтобы убедиться, что сертификат не отозван.

Если какая-либо проверка не пройдена, вы получите предупреждение — например, «Ваше подключение не защищено».

Распространённые ошибки конфигурации TLS

Даже при включённом HTTPS ошибки могут ослабить безопасность:

Устаревшие протоколы: Поддержка TLS 1.0/1.1 или SSLv3 подвергает вас известным атакам.
Слабые наборы шифров: Разрешение шифров RC4 или CBC-режима без мер защиты.
Отсутствие HSTS: Без HTTP Strict Transport Security пользователи могут быть переведены на HTTP.
Неправильное управление сертификатами: Просроченные сертификаты или неправильная конфигурация цепочки.

Используйте такие инструменты, как SSL Test от SSL Labs, для проверки вашей конфигурации.

Практический пример: включение HTTPS в Nginx

Вот минимальная конфигурация Nginx для безопасного HTTPS-сервера:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

    add_header Strict-Transport-Security "max-age=63072000" always;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Эта конфигурация использует сертификаты Let's Encrypt, включает только TLS 1.2 и 1.3 и устанавливает HSTS.

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

В чём разница между TLS и SSL?

TLS — преемник SSL. Версии SSL (2.0, 3.0) устарели из-за уязвимостей. Когда говорят «SSL-сертификат», обычно имеют в виду TLS-сертификат.

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

Современный TLS (1.3) добавляет минимальную задержку — часто всего несколько миллисекунд. С возобновлением сессий и HTTP/2 HTTPS может быть таким же быстрым или быстрее, чем HTTP.

Как получить бесплатный TLS-сертификат?

Let's Encrypt предоставляет бесплатные автоматизированные сертификаты. Инструменты вроде Certbot могут получить и продлить их для вас.

Заключение

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

Для анализа серверных логов с целью выявления ошибок TLS или проблем с производительностью попробуйте наш Анализатор логов Nginx.