Возьмем следующие nginx.conf файл конфигурации с server блоки для example.com и subdomain.example.com:
http {
...
server {
listen [::]:80 ipv6only=off default_server;
server_name example.com;
return 301 https://example.com$request_uri;
}
server {
listen [::]:443 ipv6only=off ssl default_server;
server_name example.com;
add_header Strict-Transport-Security
"max-age=63072000; includeSubDomains; preload" always;
...
}
server {
listen [::]:80 ipv6only=off;
server_name subdomain.example.com;
return 301 https://subdomain.example.com$request_uri;
}
server {
listen [::]:443 ipv6only=off ssl;
server_name subdomain.example.com;
add_header Strict-Transport-Security
"max-age=63072000; includeSubDomains; preload" always; # <-- again ???
...
}
}
В includeSubDomains Часть заголовка явно сообщает браузеру, что заголовок также применяется ко всем поддоменам.
Однако, если этот браузер посетит subdomain.example.com прежде чем увидеть example.com, это не поможет, не так ли? Чтобы прикрыть этот сценарий, мне нужно добавить такой же add_header во всех блоках сервера субдоменов тоже ... верно?
Вы правы, что лучше иметь HSTS Strict-Transport-Security заголовок везде, где он вам нужен, чтобы клиент мог его получить, даже если sub.example.com доступен до example.com или если срок действия кэшированной информации HSTS истек.
В includeSubDomains Флаг влияет на все поддомены, где он присутствует. Это означает, что includeSubDomains на sub.example.com вступает в силу *.sub.example.com вместо того *.example.com. (Это естественно, так как было бы плохо, если бы, например, example.co.uk может повлиять *.co.uk.)
Если вы не используете sub.sub.example.com ты мог бы оставить Strict-Transport-Security заголовок ваших поддоменов без этого флага.
subA.example.com не могу защитить subB.example.com.
Верный. Параметр includeSubdomains используется для принудительного использования https для всех ресурсов, связанных внутри html-страницы, обслуживаемой текущим доменом.
Цитирование https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/ :
Например, ответ HTML для https://www.example.com может включать запрос к ресурсу из https://example.com, чтобы убедиться, что HSTS установлен для всех поддоменов example.com.
Также помните, что если вы добавите add_header директиве внутри блока location {}, вам также необходимо переопределить add_header Strict-Transport-Security ... внутри этого блока. Цитирую снова:
Блоки конфигурации NGINX наследуют директивы add_header из включающих их блоков, поэтому вам просто нужно поместить директиву add_header в блок сервера верхнего уровня. Есть одно важное исключение: если блок включает саму директиву add_header, он не наследует заголовки от включающих блоков, и вам необходимо повторно объявить все директивы add_header: