Почему RFC 6797 запрещает отправку заголовка Strict-Transport-Security поверх простых HTTP-ответов?

Question

При чтении спецификации для HSTS (Strict-Transport-Security) в разделе 7.2 я вижу запрет на отправку заголовка при доступе через http вместо https:

Хост HSTS НЕ ДОЛЖЕН включать поле заголовка STS в ответы HTTP, передаваемые по незащищенному транспорту.

Почему это? Каковы риски, если это нарушается?

Answer 1

Не уверен, что если у вас есть какая-то конкретная проблема, которую вы пытаетесь решить, или вы только ради любопытства спрашиваете, это можно лучше задать на http://security.stackexchange.com/

Как и вы, я не вижу угрозы от сервера, отправляющего это по HTTP. Это на самом деле не имеет смысла, но я не уверен, существует ли риск быть честным. Если не считать того, что вы не можете правильно настроить заголовок, то, возможно, вы не готовы к внедрению HSTS, поскольку это может быть опасно в случае неправильной настройки!

Гораздо большая опасность состоит в том, что браузер должен был обрабатывать заголовок HSTS, полученный по HTTP, который в разделе 8.1 явно указывает, что он ДОЛЖЕН игнорировать:

Если HTTP-ответ получен через незащищенный транспорт, UA ДОЛЖЕН игнорировать любые существующие поля заголовка STS.

Риск здесь заключается в том, что злоумышленник (или случайно неправильно настроенный заголовок) может отключить веб-сайт только для HTTP (или части смешанного сайта только для HTTP), если браузер неправильно обработал его. Это будет эффективно вызывать DoS для этого пользователя (пользователей), пока не истечет срок действия заголовка или пока сайт не реализует HTTPS.

Кроме того, если браузер принял этот заголовок через HTTP, а не HTTPS, злоумышленник MITM мог бы истечь заголовок, установив для него максимальный возраст 0. Например, если у вас установлен длинный заголовок HSTS на https://www.example.com/ но злоумышленнику удалось опубликовать заголовок max-age=0 с includeSubDomain поверх http://example.com/, и браузер неправильно обработал это, тогда он мог бы эффективно снять защиту, которую HTTPS предоставляет вашему www сайт.

По этим причинам очень важно, чтобы клиенты (т.е. веб-браузеры) реализовали это правильно и игнорировали заголовок HSTS, если он обслуживался по HTTP, и обрабатывали его только по HTTPS. Это может быть еще одной причиной, по которой серверы RFC-состояний не должны отправлять это по HTTP - на всякий случай, если браузер реализует это неправильно, но, если честно, если это произойдет, то этот браузер подвергает риску все сайты только с HTTP, как мог бы добавить злоумышленник MITM. это как указано выше.

Answer 2

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

1. Браузер: "Я хочу http://example.com/"
2. ExampleCom: "Вы должны перейти по адресу https:// сейчас и в течение следующих 3 месяцев!"
3. Браузер: "Я хочу https://example.com/"
4. ExampleCom: [ничего]

Предоставляя только заголовок STS через HTTPS-соединения, сайт гарантирует, что по крайней мере сейчас он не указывает браузерам на недоступный сайт. Конечно, если максимальный возраст установлен на 3 месяца, а сайт HTTPS завтра не работает, эффект тот же. Это просто дополнительная защита.

Если ваш сервер не может точно определить по характеристикам запроса, осуществляется ли доступ к нему через HTTP или HTTPS, но вы считаете, что вы настроили свой веб-сайт так, чтобы он был доступен только через HTTPS (например, из-за завершения SSL/TLS в прокси-сервере nginx), должно быть безопасно обслуживать заголовок все время. Но если вы хотите обслуживать оба, например, если вы хотите обслуживать перенаправления HTTP->HTTPS с вашего сервера, узнайте, как ваш прокси-сервер сообщает вам о соединении, и начните собирать ответ заголовка STS на этом.

(Спасибо Дейрдре Коннолли за это объяснение!)