HSTS: Достаточно ли includeSubDomains в основном домене?
В моей редакции веб-администратора Plesk я только что активировал HSTS на своем основном домене www.domain.tld с помощью
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Тест на ssllabs.com говорит, что все работает нормально. Проблема в моем поддомене ( subdomain.domain.tld ). Если я тестирую свой поддомен на ssllabs, он говорит, что HSTS не активирован.
Должен ли я включать заголовок
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
и в мой субдомен, или достаточно его реализации в моем основном домене?
Я думал, добавляя includeSubDomains , нет необходимости явно добавлять его в субдомены.
Часть includeSubDomains только указывает браузеру, как только он это увидит, что запросы к другим субдоменам должны соответствовать тем же правилам HSTS (т. Е. Действующий сертификат должен присутствовать). Это не «делает вывод» о применении этого правила к вашим субдоменам, если, например, пользователь никогда раньше не заходил на ваш сайт www.domain.tld. В этом случае их браузер никогда не увидит наличие этого заголовка в вашем субдомене www и, следовательно, не будет применять правила HSTS.
Если пользователь видел этот заголовок в вашем субдомене www. -domain, затем пытается получить доступ к субдомену с недействительным сертификатом, он блокирует его и не позволяет пользователю продолжить.
Короче говоря, вам необходимо убедиться, что вы обслуживаете один и тот же заголовок HSTS во всех своих субдоменах для 100% эффективности.
В отличие от CAA, HSTS не читается из всех родительских доменов.
Так что, если вы настроили его на example.com с помощью includeSubDomains , то он не будет прочитан, если вы просто посетите www.example.com. Однако, если вы сначала посетите example.com, он будет установлен. Таким образом, в основном вы можете получить противоречивые результаты.
Вероятно, это связано с тем, что будет иметь место влияние на производительность (и конфиденциальность!) При проверке всех родительских доменов, чтобы увидеть, отправляют ли они также заголовок HSTS с includesubdomains ].
Таким образом, он должен быть установлен в используемом домене , а также на любом родительском домене (ах).
Теперь даже этого часто недостаточно для обеспечения полной защиты. Например, если вы отправили его на www.example.com и на example.com, но example.com обычно не посещается, то у большинства посетителей веб-сайта будет кэширован только вариант www в качестве домена HSTS. Так что вполне может быть возможно посетить example.com через HTTP хотя бы для одного запроса. По этой причине рекомендуется загружать один актив (например, изображение) из вашего базового домена через HTTPS при посещении вашего домена www, чтобы загружались обе политики HSTS. Также рекомендуется перенаправлять как example.com -> https://example.com -> https://www.example.com , а не example.com прямо на https://www.example.com , чтобы выбрать любую политику HSTS example.com, несмотря на влияние этого дополнительного перенаправления на производительность.
И можно иметь разные политики на каждом уровне. Например, если у вас есть некоторые поддомены, которые не находятся на HTTPS (например, intranet.example.com), тогда вы можете иметь политику HSTS на верхнем уровне без includeSubDomains и другую политику HSTS на www.example. com с includeSubDomains .
Альтернативой всему этому является предварительная загрузка домена. Это жестко кодирует весь домен (и обычно все поддомены) в коде браузера, поэтому даже первые посещения защищены. Это также не влияет на производительность проверки всех родительских доменов, поэтому действительно вступает в силу только с одной записью с includeSubDomains . Но предварительная загрузка - это серьезное обязательство, и к нему нельзя относиться легкомысленно, поскольку это в основном необратимо. Кроме того, вы не можете выполнить предварительную загрузку, если все ваши субдомены не настроены на HTTPS - по крайней мере, мы сделаем это без специальной предварительной загрузки. Еще одна причина загрузить изображение из домена верхнего уровня, чтобы активировать базовую политику до того, как вступит в силу любая необратимая предварительная загрузка!
В общем, это сложно! :-) Но стоит приложить усилия, чтобы понять это и сделать все правильно.