Коротко. SSL/TLS шифрует трафик в два этапа: сначала браузер и сервер асимметричным шифрованием (публичный и приватный ключ) договариваются об общем секретном ключе — этот этап называется handshake и занимает один цикл обмена данными (round-trip) в современном протоколе TLS 1.3, обычно 20-100 мс в зависимости от расстояния до сервера. Дальше весь трафик страницы шифруется уже симметричным ключом — он быстрее асимметричного в тысячи раз и не создаёт заметной нагрузки на скорость сайта.
Зачем два вида шифрования, а не один
У асимметричного шифрования (пара «публичный ключ — приватный ключ») есть неудобное для практики свойство — оно математически затратно, и шифровать им каждый байт трафика страницы было бы в тысячи раз медленнее, чем нужно для нормальной работы сайта. У симметричного шифрования (один общий секретный ключ на обе стороны) обратная проблема: оно быстрое, но требует, чтобы ключ был известен обеим сторонам заранее, а безопасно передать секретный ключ по незащищённому каналу — как раз то, что нужно решить. TLS обходит оба ограничения комбинацией: асимметричное шифрование используется один раз, в начале соединения, только чтобы стороны безопасно согласовали общий симметричный ключ для этой конкретной сессии, а весь дальнейший обмен данными идёт уже быстрым симметричным шифрованием.
Что происходит при handshake шаг за шагом
Handshake — процесс согласования шифрования до того, как браузер получит хоть байт содержимого страницы. В упрощённом виде для TLS 1.3 (актуальная версия протокола) это выглядит так: браузер отправляет Client Hello — список поддерживаемых версий протокола и алгоритмов шифрования, плюс часть данных для будущего ключа. Сервер отвечает Server Hello — выбранным набором алгоритмов, своим сертификатом (публичным ключом и подписью удостоверяющего центра) и своей частью данных для ключа. Обе стороны независимо вычисляют один и тот же общий секрет по алгоритму Диффи — Хеллмана, не передавая сам секрет по сети в открытом виде — это математическое свойство, из-за которого перехват трафика на этом этапе не даёт атакующему сам ключ. После этого сервер подтверждает готовность сообщением Finished, и с этого момента весь дальнейший обмен идёт по симметричному шифрованию. В TLS 1.2, который ещё встречается на старых серверах, этот же процесс занимал два цикла обмена данными вместо одного — TLS 1.3 сократил handshake вдвое именно за счёт объединения части шагов.
Роль сертификата в этом процессе
Сертификат — не про шифрование само по себе, а про то, чтобы браузер убедился: публичный ключ, который используется для handshake, действительно принадлежит нужному домену, а не подставлен кем-то посередине (классическая атака «человек посередине», man-in-the-middle). Сертификат содержит публичный ключ сайта и цифровую подпись удостоверяющего центра, который заранее проверил (на уровне DV — что заявитель управляет доменом, подробнее — в материале про выбор типа сертификата), что имеет право выдать сертификат на этот домен. Браузер проверяет подпись по цепочке до корневого центра, которому доверяет операционная система, — если цепочка сходится и домен в сертификате совпадает с адресом сайта, handshake продолжается; если нет — браузер прерывает соединение ещё до того, как получит содержимое страницы, и показывает предупреждение.
Что именно шифруется, а что видно посторонним
Здесь распространено заблуждение, что https полностью скрывает всё, включая факт обращения к конкретному сайту. Содержимое страницы, куки, данные форм, заголовки запроса — всё это действительно зашифровано и недоступно для чтения по пути между браузером и сервером. Но сам факт подключения к определённому IP-адресу виден интернет-провайдеру и любому, кто наблюдает трафик на уровне сети, а в большинстве текущих конфигураций виден и домен: при установлении соединения браузер передаёт имя домена в открытом виде в поле SNI (Server Name Indication), чтобы сервер, который обслуживает несколько сайтов на одном IP, понял, для какого из них нужно предъявить сертификат. Более новый механизм ECH (Encrypted Client Hello) шифрует и это поле, но пока поддерживается не повсеместно. Практический вывод: https защищает содержимое переписки и данные, но не скрывает сам факт визита на конкретный сайт от наблюдателя на уровне сети.
Как handshake влияет на скорость сайта
Каждое новое TLS-соединение добавляет к загрузке страницы дополнительную задержку — то самое время на handshake, обычно от 20 до 100+ миллисекунд в зависимости от географического расстояния между браузером и сервером и версии протокола (TLS 1.3 быстрее TLS 1.2 примерно вдвое по числу требуемых обменов). Для одного запроса это несущественно, но handshake происходит не для каждой отдельной картинки или скрипта на странице — современные браузеры переиспользуют уже установленное соединение для всех ресурсов с одного домена, а для повторных визитов есть механизм session resumption, который позволяет пропустить часть шагов handshake, если браузер уже подключался к этому серверу недавно. На практике корректно настроенный https почти не отражается на скорости загрузки — куда больше на неё влияют вес изображений и количество запросов, чем сам факт шифрования; подробный разбор факторов скорости — тема отдельного технического аудита.
Зачем разработчику или владельцу сайта вообще это знать
Для повседневной работы с сайтом не нужно уметь пересказать алгоритм Диффи — Хеллмана — установка и обновление сертификата не требуют этого понимания вообще. Но общее представление о handshake помогает трезво читать сообщения браузера об ошибках: понятно, почему ошибка «не тот сертификат» блокирует загрузку страницы полностью (handshake прерывается до передачи содержимого, а не после), почему смена сертификата не требует что-либо перенастраивать в самом коде сайта (шифрование — уровень транспорта, а не уровень приложения), и почему медленный сайт почти никогда не тормозит именно из-за https, если протокол настроен по актуальным стандартам.
FAQ
Правда ли что шифрование заметно замедляет сайт?
При актуальной настройке — нет. Handshake добавляет доли секунды на новое соединение, а session resumption сокращает эту задержку для повторных визитов. Куда сильнее на скорость влияют размер картинок, число запросов и настройка кеширования.
Что такое TLS 1.3 и стоит ли на него переходить?
Это актуальная версия протокола шифрования, которая сокращает handshake до одного цикла обмена данными вместо двух в TLS 1.2, и убирает часть устаревших, менее безопасных алгоритмов шифрования. Современные серверы и хостинги в 2026 году обычно уже поддерживают его по умолчанию, отдельно включать нужно редко.
Виден ли домен сайта, если весь трафик зашифрован?
В большинстве текущих конфигураций — да, через поле SNI при установлении соединения. Содержимое страницы и передаваемые данные при этом остаются зашифрованными и нечитаемыми для наблюдателя на уровне сети.
Чем публичный ключ отличается от приватного?
Публичный ключ входит в сертификат и открыто передаётся любому, кто подключается к сайту — его знание не даёт возможности расшифровать трафик. Приватный ключ хранится только на сервере и никогда не передаётся по сети — именно он математически связан с публичным и нужен для завершения handshake.
Что произойдёт, если приватный ключ сервера утечёт?
Тот, у кого оказался приватный ключ, теоретически сможет выдавать себя за сайт при атаке «человек посередине» и расшифровывать перехваченный трафик. При подозрении на утечку сертификат нужно немедленно отозвать у центра сертификации и перевыпустить с новой парой ключей — это не тот случай, где можно подождать до планового обновления.
Хотите понять, насколько безопасно настроен SSL на вашем сайте
Бесплатный аудит проверит конфигурацию шифрования, версию протокола и покажет, есть ли технические слабые места.
Проверка SSL-сертификата
Смотрим срок действия и цепочку доверия. Ошибка «unable to get local issuer certificate» означает недоданный промежуточный сертификат.
# срок действия и издатель
openssl s_client -connect example.ru:443 -servername example.ru < /dev/null 2>/dev/null \
| openssl x509 -noout -dates -issuer
# полная цепочка
openssl s_client -connect example.ru:443 -showcerts < /dev/null 2>/dev/null | grep "s:"