HSTS no Nginx: o cabeçalho Strict-Transport-Security também deve ser adicionado nos blocos do servidor de subdomínio?

Question

Vamos usar o seguinte arquivo de configuração nginx.conf com server blocos para example.com e 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 ???
        ...
    }
}

A parte includeSubDomains do cabeçalho aparentemente diz ao navegador que o cabeçalho se aplica a todos os subdomínios também.

No entanto, se esse navegador fosse visitar subdomain.example.com antes de ver example.com , isso não ajudaria em nada, seria? Então, para cobrir este cenário, eu preciso adicionar o mesmo add_header em todos os blocos de servidores subdomínios também ... certo?

    

Answer 1

Você está certo de que é melhor ter o cabeçalho HSTS Strict-Transport-Security em todos os lugares para garantir que um cliente o obtenha, mesmo se sub.example.com for acessado antes de example.com ou se as informações HSTS em cache tiverem expirado.

O includeSubDomains flag afeta todos os subdomínios de onde ele está presente. Isso significa que includeSubDomains on sub.example.com entra em vigor em *.sub.example.com em vez de *.example.com . (Isso é natural, pois seria ruim se, por exemplo, example.co.uk pudesse afetar *.co.uk .)

• Se você não usar sub.sub.example.com , poderá deixar o cabeçalho Strict-Transport-Security de seus subdomínios sem este sinalizador.

• subA.example.com não pode proteger subB.example.com .

Answer 2

Correto. A opção includeSubdomains é usada para impor https em todos os recursos vinculados dentro de uma página html servida pelo domínio atual.

Citando o link :

For example, the HTML response for https://www.example.com can include a request to a resource from https://example.com, to make sure that HSTS is set for all subdomains of example.com.

Tenha também cuidado com o fato de que, se você adicionar uma diretiva add_header dentro de um bloco de localização {}, também precisará redefinir add_header Strict-Transport-Security ... nesse bloco. Citando novamente:

NGINX configuration blocks inherit add_header directives from their enclosing blocks, so you just need to place the add_header directive in the top‑level server block. There’s one important exception: if a block includes an add_header directive itself, it does not inherit headers from enclosing blocks, and you need to redeclare all add_header directives: