HSTS: преимущества, риски и безопасное развертывание

HSTS: преимущества безопасности и риски развертывания

HSTS — один из самых простых механизмов HTTP-безопасности с точки зрения настройки и одновременно один из тех, которые легче всего внедрить слишком агрессивно.

HTTP Strict Transport Security, или HSTS, сообщает браузеру, что к домену необходимо обращаться только по HTTPS. После того как браузер запомнил эту политику, попытка открыть http://example.com приводит к переходу на HTTPS ещё до отправки небезопасного HTTP-запроса. HSTS также запрещает пользователю обходить ошибки сертификата для этого хоста. (rfc-editor.org)

Преимущество для безопасности существенно: HSTS снижает возможность атак с понижением уровня защиты HTTPS и SSL stripping. Но есть и важный риск развертывания: длительный max-age, includeSubDomains или HSTS preloading могут сделать неправильно настроенные или работающие только по HTTP хосты недоступными до тех пор, пока проблема с HTTPS не будет устранена.

Краткий ответ

HSTS — это HTTP-заголовок ответа, который сообщает поддерживающим его браузерам, что домен должен использовать HTTPS в течение заданного периода.

Типичная политика выглядит так:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Здесь max-age=31536000 означает, что браузер будет помнить HSTS-политику примерно один год. includeSubDomains распространяет эту политику на поддомены. Браузеры принимают HSTS-заголовок только через защищённое соединение; заголовок HSTS, полученный по обычному HTTP, игнорируется. (rfc-editor.org)

HSTS усиливает защиту HTTPS-развертывания. Он не заменяет HTTPS, TLS-сертификаты, редиректы или корректную конфигурацию сервера.

Ключевые факты

Параметр	Что делает	Основной риск
`max-age`	Сохраняет HSTS-политику на заданное количество секунд	Ошибки могут сохранять последствия до истечения политики
`includeSubDomains`	Распространяет HSTS на поддомены	Поддомены, работающие только по HTTP, могут стать недоступными
`preload`	Сигнализирует о намерении участвовать в программах предварительной загрузки браузеров	Создаёт более долгосрочное обязательство для всего домена
`max-age=0`	Удаляет динамически сохранённую HSTS-политику	Браузер сначала должен безопасно подключиться к сайту, чтобы получить её

RFC 6797 определяет max-age и includeSubDomains. Механизм preload — это дополнительная функция экосистемы браузеров, а не часть самой спецификации HSTS. (rfc-editor.org)

Почему HSTS важен

Рассмотрим сайт, который перенаправляет посетителей с HTTP на HTTPS:

http://example.com
        ↓
301 redirect
        ↓
https://example.com

Такой редирект помогает обычным пользователям перейти на HTTPS, однако первый HTTP-запрос всё ещё остаётся незашифрованным. Злоумышленник, контролирующий сеть, потенциально может вмешаться до установления HTTPS-соединения. MDN описывает это как окно первого подключения, в котором SSL stripping всё ещё возможен. (developer.mozilla.org)

После того как браузер запомнит HSTS-политику, последовательность меняется:

User requests http://example.com
        ↓
Browser sees stored HSTS policy
        ↓
Browser changes request to HTTPS
        ↓
HTTPS connection

Небезопасный запрос не отправляется.

В этом и состоит важное различие: HTTP-to-HTTPS redirect выполняется после того, как HTTP-запрос достигает сервера, тогда как HSTS позволяет браузеру локально перевести запрос на HTTPS ещё до его отправки.

INTERNAL LINK: Как работают HTTPS и TLS

Как работает HSTS

Когда HTTPS-ответ содержит:

Strict-Transport-Security: max-age=31536000

браузер записывает этот хост как HSTS-хост. Значение max-age действует как время жизни политики, отсчитываемое с момента получения заголовка браузером. Последующие подходящие HTTP-запросы переводятся на HTTPS. Каждый новый HSTS-ответ может продлевать срок действия политики. (rfc-editor.org)

Есть ещё одно важное поведение: ошибки TLS-сертификата для HSTS-хоста становятся необходными. Обычно при предупреждении о сертификате пользователь иногда может получить возможность продолжить. HSTS намеренно убирает этот обходной путь, поскольку его наличие подорвало бы саму политику безопасности. (developer.mozilla.org)

Во время атаки это полезно, но при операционной ошибке может создать серьёзную проблему.

Риск развертывания

Главная ошибка при использовании HSTS — считать самую строгую конфигурацию правильной отправной точкой.

Представим такую структуру домена:

example.com
www.example.com
api.example.com
legacy.example.com
internal.example.com

Допустим, legacy.example.com всё ещё работает только по HTTP. Немедленное включение следующей политики на родительском домене было бы рискованным:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Получив такую политику, браузер может начать требовать HTTPS для дочерних хостов example.com. Если legacy.example.com не способен обслуживать корректный HTTPS, пользователи могут потерять к нему доступ.

Именно поэтому includeSubDomains следует включать только после проверки соответствующего списка поддоменов и подтверждения поддержки HTTPS. MDN отдельно предупреждает, что эта директива может сделать недоступными поддомены, которые ещё не поддерживают HTTPS. (developer.mozilla.org)

Более безопасное развертывание

Безопаснее внедрять HSTS постепенно, а не включать строгую политику сразу.

Сначала убедитесь, что основной домен корректно работает по HTTPS. Затем задайте небольшой срок действия HSTS, например:

Strict-Transport-Security: max-age=300

Это создаёт пятиминутное окно действия политики.

После проверки обновления сертификатов, редиректов, поведения CDN, маршрутов приложения, ответов с ошибками и другой инфраструктуры постепенно увеличьте срок:

Strict-Transport-Security: max-age=86400

Затем, после дополнительной проверки:

Strict-Transport-Security: max-age=31536000

Добавляйте includeSubDomains только тогда, когда HTTPS надёжно поддерживается во всём предполагаемом дереве поддоменов.

Такое постепенное увеличение — рекомендация SeoNest по развертыванию, а не требование RFC 6797. Текущий сервис HSTS preload также рекомендует операторам постепенно увеличивать max-age перед отправкой домена на предварительную загрузку. (hstspreload.org)

HSTS Preloading

У обычного HSTS есть ограничение: браузер обычно должен сначала получить HSTS-заголовок, прежде чем узнает о политике. Поэтому у нового профиля браузера сохраняется окно первого подключения.

HSTS preloading решает эту проблему за счёт поставки списка HSTS-доменов вместе с браузером. Chromium указывает, что Chrome поддерживает такой preload-список, а другие браузеры используют списки, основанные на нём. (chromium.org)

Текущие требования для отправки домена на hstspreload.org включают действующий сертификат, перенаправление HTTP на HTTPS на том же хосте при наличии HTTP, поддержку HTTPS на всех поддоменах, includeSubDomains, preload и max-age не менее 31536000 секунд. (hstspreload.org)

Типичный заголовок, готовый для preload, выглядит так:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Однако включать preloading без тщательной проверки не следует. Сервис preload прямо предупреждает проекты не активировать preload по умолчанию и отмечает, что удаление из списка может занимать значительное время. В текущих рекомендациях сам HSTS поддерживается, тогда как к HSTS preloading предлагается подходить осторожнее. (hstspreload.org)

Пример для Nginx

Для Nginx:

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

Параметр always заставляет Nginx добавлять заголовок независимо от статуса ответа. У Nginx также есть особые правила наследования для add_header, поэтому вложенные конфигурации server или location следует проверять отдельно, а не предполагать, что заголовок наследуется везде. (nginx.org)

Не отправляйте HSTS с HTTP-only endpoint в расчёте на то, что браузер ему доверится. Браузеры намеренно игнорируют HSTS-заголовки, полученные по незащищённому HTTP. (developer.mozilla.org)

Проверка развертывания

Проверьте заголовки HTTPS-ответа напрямую:

curl -I https://example.com

curl -I получает HTTP-заголовки ответа, позволяя проверить, действительно ли присутствует Strict-Transport-Security. (curl.se)

Найдите:

Strict-Transport-Security: max-age=31536000

Также проверьте редиректы, ответы с ошибками, важные поддомены и действительность сертификатов. Если вы планируете использовать includeSubDomains, проверки только apex domain недостаточно.

Распространённые заблуждения

HSTS перенаправляет HTTP на HTTPS на сервере. Не совсем. После того как политика уже известна, браузер может перевести запрос на HTTPS ещё до создания небезопасного HTTP-соединения.

HSTS исправляет истёкший сертификат. Нет. HSTS делает обработку ошибок сертификата строже. Поэтому неисправный сертификат может полностью сделать HSTS-защищённый сайт недоступным, пока проблема с сертификатом не будет устранена.

Удаление заголовка сразу отключает HSTS. Нет. Ранее сохранённая политика остаётся активной до истечения её max-age. Отправка max-age=0 удаляет динамическую HSTS-политику, когда браузер успешно получает такой ответ по HTTPS. (rfc-editor.org)

Каждому HTTPS-сайту следует сразу включать preload. HSTS и HSTS preloading — это разные решения. Preloading создаёт более серьёзное операционное обязательство и должен применяться только после осознанной проверки всего доменного пространства.

FAQ

Улучшает ли HSTS SEO?

HSTS в первую очередь является механизмом транспортной безопасности. В источниках, использованных для этой статьи, Google не документирует сам HSTS как прямой ranking factor. Поэтому его ценность следует оценивать главным образом с точки зрения безопасности HTTPS и надёжности развертывания, а не предполагать влияние на позиции в поиске.

Влияет ли HSTS на первый визит?

Обычный динамически изучаемый HSTS не может полностью защитить браузер, который ещё не знает политику сайта. Preloading может устранить этот первоначальный разрыв для включённых в список доменов. (developer.mozilla.org)

Можно ли отключить HSTS?

Для динамически сохранённой политики сервер может отправить:

Strict-Transport-Security: max-age=0

по HTTPS. После этого браузер удаляет сохранённую HSTS-политику данного хоста в соответствии с RFC 6797. (rfc-editor.org)

Следует ли использовать HSTS для API?

Если к API hostname обращаются user agents, поддерживающие HSTS, он может получить те же преимущества транспортной политики. Однако решение о применении includeSubDomains на родительском домене по-прежнему зависит от готовности всего соответствующего дерева доменов к HTTPS.

Итог

HSTS закрывает важную уязвимость обычного HTTP-to-HTTPS перенаправления, сообщая браузерам, что в будущих соединениях необходимо использовать HTTPS. Его сила заключается в постоянстве: браузеры запоминают политику и не допускают небезопасный fallback.

Но это же постоянство создаёт риск при развертывании.

Используйте HSTS осознанно. Сначала стабилизируйте HTTPS, начните с управляемого max-age, расширяйте область действия только после тестирования, а includeSubDomains и preloading воспринимайте как инфраструктурные обязательства, а не как безобидные параметры заголовка.

Источники

RFC Editor — RFC 6797: HTTP Strict Transport Security (HSTS), November 2012. Определяет обработку HSTS, max-age, includeSubDomains, срок действия и удаление политики. (rfc-editor.org)
MDN Web Docs — Strict-Transport-Security header. Практическое поведение браузеров, синтаксис, обработка сертификатов, поддомены и контекст preload. (developer.mozilla.org)
MDN Web Docs — Transport Layer Security. Поведение при переходе на HTTPS, SSL stripping и ограничение первого подключения для динамически изучаемого HSTS. (developer.mozilla.org)
Chromium — HTTP Strict Transport Security. Описание поведения HSTS в Chromium и preload-списков браузеров. (chromium.org)
HSTS Preload List Submission — hstspreload.org. Текущие требования preload, операционные предупреждения и рекомендации по отправке домена. (hstspreload.org)
NGINX — ngx_http_headers_module. Официальная документация по add_header, always и наследованию заголовков. (nginx.org)
curl — Tutorial. Официальная документация по использованию -I / --head для проверки HTTP-заголовков. (curl.se)