HSTS: как заставить браузер всегда открывать сайт только по HTTPS

HSTS (HTTP Strict Transport Security) — это специальная настройка сайта, которая запрещает браузеру открывать его по незащищённому HTTP, даже если пользователь сам вбил адрес без «https://» или перешёл по старой ссылке. Без HSTS доля первого обращения к сайту всё равно может пройти по открытому каналу — и именно этим пользуется классическая атака «понижения протокола».

Разве SSL-сертификат сам по себе не решает эту проблему?

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

Как именно происходит атака, от которой защищает HSTS?

Такая атака называется SSL-стриппинг («срыв SSL»). Злоумышленник встаёт между пользователем и сайтом и подменяет ответ сервера: вместо редиректа на HTTPS пользователь продолжает работать по открытому HTTP-соединению, даже не замечая подмены. Внешне страница может выглядеть почти так же, как настоящая, но весь трафик — пароли, данные банковских карт, переписка — идёт в открытом виде и доступен для перехвата. Пользователь может не увидеть привычного значка замка и не обратить на это внимания, особенно с телефона, где адресная строка часто скрыта или урезана.

Так как же HSTS это предотвращает?

Сайт присылает браузеру специальный заголовок Strict-Transport-Security с указанием, что в течение определённого времени (обычно от нескольких месяцев до пары лет) браузер должен обращаться к этому домену только по HTTPS — без исключений, даже если пользователь сам наберёт «http://» в адресной строке. Браузер запоминает это правило и на все последующие запросы к сайту автоматически подставляет HTTPS ещё до отправки самого запроса в сеть. То есть подменять нечего: перехватчик просто не увидит открытого HTTP-запроса, который можно было бы исказить.

А что если браузер зашёл на сайт впервые и ещё не «запомнил» правило?

Это действительно слабое место обычного HSTS — первый визит остаётся уязвимым, ведь браузер ещё не получил заголовок. Для решения этой проблемы придумали механизм preload-списков: крупные разработчики браузеров ведут единый список доменов, которые заранее «зашиты» в сам браузер как HTTPS-only, ещё до первого обращения к сайту. Владелец сайта может подать заявку на включение своего домена в такой список, и тогда защита действует буквально с самого первого клика, независимо от истории посещений конкретного пользователя.

Есть ли риски или неудобства при включении HSTS?

Главный риск — включить HSTS на сайте, который ещё не до конца готов работать по HTTPS. Если на сайте есть страницы, поддомены или API, доступные только по HTTP, они станут недоступны для браузера, который уже запомнил правило. Из-за этого HSTS рекомендуют включать поэтапно: сначала с небольшим сроком действия и без правила для поддоменов, затем — постепенно увеличивать срок и охват, убедившись, что весь сайт и все связанные сервисы стабильно работают по HTTPS.

Ещё один нюанс: пока действует срок HSTS, у пользователя нет простого способа «согласиться» открыть сайт по HTTP, даже если это временно нужно — например, при локальной разработке или тестировании. Браузер просто откажется выполнять такой запрос, и это стоит учитывать при настройке тестовых окружений.

Как понять, что HSTS настроен правильно?

Проще всего проверить заголовки ответа сервера через инструменты разработчика в браузере или специализированные онлайн-сервисы для анализа безопасности сайта — они показывают, отдаётся ли заголовок Strict-Transport-Security, какой у него срок действия и включены ли дополнительные параметры вроде распространения правила на поддомены. Если заголовок отсутствует или указан с ошибкой, механизм просто не сработает, и сайт останется уязвим к атакам на первое соединение, хотя сам SSL-сертификат при этом может быть настроен идеально.

Кому в первую очередь стоит задуматься о HSTS?

В первую очередь — сайтам, где через соединение передаются чувствительные данные: формы входа, платежи, личные кабинеты, корпоративные системы. Для интернет-магазинов, онлайн-сервисов и любых площадок, где пользователи вводят логины и пароли, HSTS — это разумное дополнение к обычному SSL-сертификату, которое закрывает конкретную и хорошо изученную уязвимость первого соединения.

Именно поэтому в «Клауд АйСи» при подключении SSL-сертификатов для сайтов и облачных сервисов также помогают корректно настроить сопутствующие параметры безопасности соединения, включая HSTS, чтобы защита работала полноценно, а не только на уровне отдельного сертификата.

Интересный факт напоследок?

Идея HSTS не нова: сама технология и связанный с ней заголовок обсуждались и стандартизировались ещё в начале 2010-х годов, а инициатива с preload-списком, «зашитым» прямо в браузеры, стала логичным продолжением — сегодня в этот список включены домены крупнейших мировых сервисов, для которых HTTP-соединение технически заблокировано на уровне самого браузера, а не только настройками сервера.