«У нас редирект с HTTP на HTTPS». Есть клиенты, для которых этого мало

Мы закрывали замечание аудитора: часть внутреннего сервиса отвечала по HTTP. Поставили редирект на HTTPS, показали, что по http:// теперь приходит 301, замечание сняли.

Через несколько недель я вернулся к этому же сервису с другой задачей и посмотрел на редирект внимательнее. Запрос, который получает 301, - это полноценный HTTP-запрос. Он уже ушёл. В нём был путь, параметры и заголовок Cookie.

Редирект не отменяет запрос. Он отвечает на него.

Дальше я полез проверять, кто вообще в наше время попадает на этот редирект, - и картина оказалась интереснее, чем я думал.

Кто ещё шлёт открытый запрос

Первое, что я предполагал: человек набирает example.com без схемы, браузер идёт по HTTP, получает 301. Так было раньше. Сегодня это неверно: Chrome подставляет https:// в адресной строке с версии 90 и с версии 115 повышает до HTTPS обычные переходы, Firefox и Safari делают то же самое. Первый запрос современного браузера уходит по HTTPS, а на HTTP он откатывается, только если по HTTPS не вышло.

Значит, открытый запрос шлют другие: сам этот откат при неудаче; ссылки, в которых схема написана явно как http:// - в письмах, в документации, в закладках; клиенты без такой логики - curl, скрипты, встроенные вебвью в приложениях, старые устройства; и интеграции, которые кто-то настроил на http:// и с тех пор не трогал.

Это и есть окно, которое закрывают HSTS и предзагрузка. Оно уже, чем было пять лет назад, но оно открыто, и вот что через него уезжает:

Полный путь и строка запроса. Адрес страницы говорит больше, чем кажется: /orders/48213/invoice - это не просто «сайт магазина».

Cookie без флага Secure. Флаг Secure означает «не отправлять по незашифрованному соединению». Его ставят не всегда, и без него сессионная кука уезжает в открытом виде вместе с первым же запросом.

Сам факт обращения. Домен виден наблюдателю и при HTTPS, а вот путь запроса - уже нет.

$ curl -s -o /dev/null -D- http://github.com/
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Location: https://github.com/

Ответ правильный. Вопрос в том, что произошло до него.

Тот, кто находится в том же канале - открытый Wi-Fi, скомпрометированный домашний роутер, промежуточный узел, - может не только прочитать этот запрос, но и ответить на него вместо сервера: отдать свою страницу или редирект на похожий домен. Проверить подлинность такого ответа клиенту нечем: TLS в этом обмене ещё не начался.

HSTS закрывает второй визит, не первый

Заголовок Strict-Transport-Security предписывает браузеру обращаться к этому домену только по HTTPS - и указывает, сколько секунд это правило действует.

$ curl -s -o /dev/null -D- https://github.com/ | grep -i strict
strict-transport-security: max-age=31536000; includeSubdomains; preload

max-age=31536000 - год. После первого успешного захода по HTTPS браузер запоминает правило и дальше подставляет https:// сам, даже если пользователь набрал http://. Никакого открытого запроса больше не будет.

Ключевые слова - «после первого». Заголовок приезжает по HTTPS, а чтобы его получить, надо сначала попасть на HTTPS. Первый визит с нового устройства, из нового браузера, после очистки данных сайта не защищён по определению.

Директива includeSubDomains распространяет правило на все поддомены. Без неё правило действует ровно на тот хост, который его прислал, и mail.example.com остаётся открытым, даже если example.com закрыт. С ней - накрываются все поддомены разом, включая те, о которых вы забыли, и те, которых ещё нет. Это её главное свойство и главная опасность одновременно.

Предзагрузка закрывает и первый визит

Список предзагрузки - это перечень доменов, зашитый прямо в браузер. Для домена из него правило HTTPS действует заранее, и открытого запроса не бывает вообще.

Условия входа: базовый домен отдаёт по HTTPS заголовок с max-age не меньше года, с includeSubDomains и с preload; сертификат валиден; а запрос на 80-й порт редиректом уходит на HTTPS того же хоста. Именно из-за последнего условия заявки и отклоняют чаще всего: схема http://example.com → https://www.example.com его не выполняет. Статус проверяется запросом:

$ curl -s 'https://hstspreload.org/api/v2/status?domain=github.com'
{
  "name": "github.com",
  "status": "preloaded",
  "bulk": true,
  "preloadedDomain": "github.com"
}

Подставьте свой домен и посмотрите на status. preloaded - домен в списке. pending - заявка принята, но в браузеры ещё не уехала, то есть защиты пока нет. unknown - домена в списке нет.

Почему я бы не спешил включать предзагрузку

Механизм необратимый по времени. Список едет в браузер вместе с его обновлением - и удаление из списка едет так же.

Порядок выхода такой: убрать preload из заголовка (обычно выставив max-age=0), подать заявку на исключение, дождаться, пока домен переведут в состояние ожидания удаления, а потом - пока обновятся браузеры пользователей. Первые два шага занимают дни, последний - месяцы. Всё это время ваш домен и все его поддомены доступны только по HTTPS.

Ломается на этом обычно не основной сайт, а то, о чём не подумали: служебный поддомен со старым оборудованием, у которого HTTPS нет; внутренний стенд; интеграция с подрядчиком, ходящая на HTTP-ручку. includeSubDomains накрывает их все.

Поэтому порядок такой: сначала убедиться, что по HTTPS работает всё, включая поддомены, которых вы не помните; потом поставить max-age на несколько минут и посмотреть; потом поднять до года; и только потом добавлять preload.

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

Что стоит проверить заодно

Флаг Secure на всех cookie. Он бесплатный и закрывает главное, что уезжает в открытом виде. Ставится вместе с HttpOnly и SameSite.

Редирект в один шаг. Частая схема - http://example.com → http://www.example.com → https://www.example.com. Здесь два открытых запроса вместо одного, и промежуточный редирект тоже можно подменить. Правильно - сразу на HTTPS того же хоста, а уже оттуда, если нужно, на www. Это же условие требуется для попадания в список предзагрузки.

Ссылки в письмах и в документации. Ссылка с http:// внутри письма - это тот самый первый запрос, и приходит он не от пользователя, набравшего адрес, а от вас.

Ограничения

Ни HSTS, ни предзагрузка не защищают от подмены самого домена: тот, кто увёл человека на похожий домен, получает на него валидный сертификат, и всё описанное работает у него ровно так же, как у вас.

И они ничего не делают с клиентами, которые HSTS не поддерживают: curl без специальных ключей, самодельные скрипты, часть встроенных вебвью. Для них единственная защита - чтобы адрес с http:// вообще нигде не был записан.

Что посмотреть у себя

Запросить http://ваш-домен и посмотреть, приходит ли 301 и куда он ведёт. Отдельно проверить www и все поддомены, которые вы знаете.

Проверить наличие Strict-Transport-Security в ответе по HTTPS и значение max-age. Часто там стоит несколько минут, оставшихся с этапа проверки.

Проверить статус домена в списке предзагрузки запросом к hstspreload.org.

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