HSTS preload: requisitos da lista de pré-carregamento, riscos e como verificar o cabeçalho e o status

1. O que é a lista de preload HSTS

O HTTP Strict Transport Security é definido na RFC 6797. O servidor envia Strict-Transport-Security: max-age=… por HTTPS, e o navegador guarda por max-age segundos que aquele host só pode ser acessado por HTTPS. Enquanto o navegador do visitante não tiver recebido o cabeçalho ao menos uma vez, nada protege a primeira requisição http:// sem criptografia, e um atacante na mesma rede pode interceptá-la. A RFC descreve essa fraqueza do primeiro acesso e sugere políticas pré-configuradas como uma resposta possível.

A lista de preload é essa resposta na prática. Quem mantém a lista é o projeto Chromium, e as novas entradas são gravadas diretamente no código-fonte do Chrome. Segundo a página de HSTS do projeto Chromium e o hstspreload.org, o Firefox, o Safari e o Edge mantêm listas próprias baseadas na do Chrome. Em qualquer versão do navegador que traga a entrada, um domínio pré-carregado só abre por HTTPS desde a primeira execução; e, como os envios precisam incluir includeSubDomains, o mesmo vale para todos os nomes abaixo dele.

Três detalhes costumam ser mal entendidos:

• A diretiva preload não faz nada no navegador. Ela não faz parte da RFC 6797, e os navegadores ignoram diretivas que não reconhecem. Ela serve para avisar aos mantenedores da lista que o dono do domínio concorda com a inclusão. A partir do momento em que o seu cabeçalho traz essa diretiva, qualquer pessoa pode enviar o seu domínio pelo formulário.
• Só entram domínios registráveis inteiros. Você envia example.com, não www.example.com nem loja.example.com, e a entrada cobre todos os subdomínios, inclusive os internos, que nem são acessíveis pela internet.
• Alguns domínios de topo são pré-carregados por inteiro. Qualquer domínio em .app ou .dev, por exemplo, já só funciona por HTTPS nos navegadores que usam a lista, tenha o dono enviado algo ou não.

2. Você ainda precisa de preload?

Para a maioria dos sites, provavelmente não. O próprio site de envio diz hoje que o HSTS é recomendado, mas o preload do HSTS não. O Chrome e o Safari tentam HTTPS automaticamente nas navegações que começam com http://, com ou sem política HSTS, e por isso a brecha da primeira visita, que o preload veio fechar, ficou bem menor. Segundo o hstspreload.org, o preload só acrescenta proteção quando esses upgrades automáticos falham por causa de um atacante ativo, e o benefício é mínimo perto do que o próprio HSTS oferece.

Ainda assim, ele pode fazer sentido quando as três condições abaixo valem ao mesmo tempo:

• um downgrade logo na primeira visita importa para você, por exemplo porque as pessoas fazem login ou pagam em redes públicas;
• todos os subdomínios atuais e futuros, incluindo os internos e os hospedados por fornecedores, conseguem servir HTTPS com um certificado válido;
• você pretende manter o domínio, e o HTTPS nele, por anos.

Deixe de lado, ou adie, se equipes ou fornecedores cuidam de subdomínios que você não controla totalmente, se há hosts internos sob o domínio público, se o domínio é de uma campanha passageira ou se você pode vendê-lo ou repassá-lo: a entrada acompanha o domínio até o próximo dono enquanto ninguém pedir a remoção. Um cabeçalho HSTS bem configurado, sem preload, já protege todo visitante que volta.

3. Os requisitos exatos de envio

O hstspreload.org confere estas condições no envio, e você precisa continuar atendendo a elas depois: domínios que deixam de atendê-las podem ser removidos, e tirar preload do cabeçalho deixa o domínio apto ao formulário de remoção na hora.

A regra do redirecionamento pega muitos sites. Se https://example.com/ redireciona para https://www.example.com/, é essa resposta de redirecionamento que precisa trazer o cabeçalho completo. O cabeçalho da página www não conta, porque uma política definida por www.example.com nunca vale para o domínio base. Um cabeçalho que passa na verificação fica assim:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

4. Os riscos: por que o preload é difícil de desfazer

• A remoção leva meses. Remover é uma mudança no código-fonte que só chega às pessoas com as atualizações do navegador. A página de remoção informa que pode levar de 6 a 12 semanas para alcançar a maioria dos usuários do Chrome, e talvez mais em outros navegadores. Um navegador que nunca é atualizado mantém a entrada antiga.
• Subdomínios sem HTTPS param de funcionar. Casos típicos: hosts de intranet que só resolvem no DNS interno, painéis de impressoras, roteadores e storages com certificados autoassinados, servidores de homologação esquecidos e serviços de fornecedores apontados por CNAME, como central de ajuda, página de status ou links de rastreamento de cliques em e-mails, que só respondem por HTTP. Num navegador com o seu domínio pré-carregado, eles falham sem nenhuma forma de contornar o erro.
• Erros de certificado viram bloqueio total. Num host com HSTS, a RFC 6797 exige que o navegador encerre a conexão diante de qualquer erro de certificado, sem deixar o visitante prosseguir. Um certificado vencido em qualquer subdomínio bloqueia todo mundo até ser trocado; por isso, automatize a renovação e monitore as datas de vencimento antes de enviar.
• Quem já visitou mantém a política guardada. Sair da lista não apaga o que os navegadores aprenderam com o seu cabeçalho. Com um max-age de dois anos, essa cópia dura dois anos, a menos que o visitante volte e receba max-age=0 por HTTPS.
• Envio acidental. Um cabeçalho copiado de um modelo que já traz preload basta para qualquer pessoa enviar o seu domínio. Deixe a diretiva de fora até concluir o plano da próxima seção.

5. Um plano de max-age em etapas antes do envio

O hstspreload.org recomenda aumentar o max-age em etapas, com includeSubDomains desde a primeira. Em cada etapa, procure páginas quebradas e acompanhe métricas como tráfego, logins e receita, corrija o que aparecer e espere pelo menos o max-age completo da etapa antes de avançar. Dá para passar pelas etapas primeiro com um grupo de teste, mas depois todos os usuários precisam passar por elas.

No nginx, envie o cabeçalho a partir do bloco server de HTTPS com o parâmetro always, para que as páginas de erro também o tragam, e mantenha o redirecionamento HTTP no mesmo host. Uma linha add_header dentro de um bloco location substitui ali os cabeçalhos definidos no nível do server (módulo de cabeçalhos do nginx).

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # etapa 1: troque o valor a cada etapa
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}

Só a subida em etapas leva mais de cinco semanas. Depois do envio, segundo o hstspreload.org, uma entrada nova pode levar vários meses para chegar à versão estável do Chrome; por isso, o preload nunca é uma solução rápida para uma data de lançamento.

6. Como verificar o seu cabeçalho HSTS

No terminal, confira as três respostas que importam:

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://www.example.com/

A primeira deve retornar 301 ou 308 com Location: https://example.com/; ela não precisa de cabeçalho HSTS, porque os navegadores ignoram HSTS recebido por HTTP sem criptografia. A segunda precisa trazer strict-transport-security com as três diretivas, mesmo que ela própria redirecione para o www. A terceira também deve enviar o cabeçalho, porque quem só abre o www nunca recebe a política do domínio base. No Windows, use curl.exe e -o NUL.

Fique de olho nestes erros:

• Dois cabeçalhos HSTS. Quando a CDN e o servidor de origem adicionam um cada, a RFC 6797 manda o navegador processar só o primeiro, e a verificação do hstspreload.org acusa “Multiple HSTS headers” como erro. Defina qual camada é dona do cabeçalho.
• Uma diretiva com erro de digitação. Os navegadores descartam sem aviso as diretivas que não reconhecem; um includeSubdomain sem o s final deixa os subdomínios descobertos sem ninguém perceber.
• Ausente em algumas respostas. A página inicial tem o cabeçalho, mas as páginas de erro, a API ou os arquivos estáticos servidos por outra camada não têm.

No Chrome DevTools, abra o painel Network e digite http://example.com/ na barra de endereços depois que o navegador já tiver guardado a política. A primeira entrada mostra 307 Internal Redirect com Non-Authoritative-Reason: HSTS: o navegador mudou para HTTPS por conta própria, antes de qualquer requisição chegar ao servidor. A referência do MDN traz a sintaxe do cabeçalho.

7. Como verificar o status na lista de preload

• hstspreload.org. Digite o domínio no formulário. Ele mostra se o domínio está pré-carregado, pendente ou fora da lista, junto com os erros e avisos em relação aos requisitos atuais. Um domínio pendente ainda não está protegido: ele ainda precisa sair numa versão do navegador.
• chrome://net-internals/#hsts. No Chrome, informe o domínio em “Query HSTS/PKP domain”. Os campos que começam com static_ vêm da lista embutida naquela versão do navegador; os que começam com dynamic_ vêm dos cabeçalhos que o navegador recebeu. “Delete domain security policies” apaga só a parte dinâmica, então uma entrada pré-carregada continua lá até uma atualização do navegador removê-la.
• Outros navegadores. O Firefox, o Safari e o Edge distribuem cópias próprias, derivadas da lista do Chrome, em seus próprios calendários; por isso, uma inclusão ou remoção pode chegar a eles em momentos diferentes.

Repita a verificação depois de mudanças no DNS, na CDN ou nos certificados. O hstspreload.org avisa que domínios que deixarem de atender aos requisitos poderão ser removidos automaticamente no futuro.

8. Como sair da lista: passos e prazos da remoção

1. Continue servindo HTTPS com certificado válido no domínio base; o formulário de remoção confere isso.
2. Envie um cabeçalho HSTS sem preload. O hstspreload.org trata esse cabeçalho como o pedido de remoção. Mantenha includeSubDomains e um max-age longo se quiser continuar com HSTS, ou envie max-age=0 para desligá-lo de vez.
3. Envie o domínio pelo formulário de remoção.
4. Enquanto espera, dê um certificado válido ao subdomínio que motivou a decisão ou mude-o para outro domínio: a remoção pode levar de 6 a 12 semanas para chegar à maioria dos usuários do Chrome, e mais em outros navegadores.
5. Não volte a enviar preload, a não ser que queira entrar na lista de novo.

O max-age=0 só funciona por HTTPS e só para os visitantes que voltam e o recebem. Planeje pelo caminho mais lento: um navegador desatualizado que ainda tenha a entrada embutida, ou uma política de dois anos já guardada, pode continuar forçando HTTPS muito depois de você ter mudado de ideia.

9. O que o snapshot gratuito do Sitelemetry mostra

O snapshot gratuito de prontidão para lançamento do Sitelemetry (Launch Readiness Snapshot) roda oito verificações passivas em um domínio público, sem cadastro, e devolve uma pontuação com o resultado de cada verificação. Duas delas tratam de HSTS:

• A verificação de cabeçalhos de segurança HTTP lê a página inicial do domínio informado, depois de até cinco redirecionamentos. Ela classifica como média a ausência de Strict-Transport-Security num destino HTTPS e mostra o valor observado.
• A verificação de redirecionamento HTTPS marca como baixo um max-age abaixo de 180 dias (15.552.000 segundos) quando você informa só o domínio ou um endereço https://. Nas etapas 1 a 3 do plano, esse resultado é esperado.

O snapshot não verifica includeSubDomains, a diretiva preload, os seus subdomínios nem o status na lista; para isso, use o hstspreload.org e os comandos curl acima. Para abrir primeiro o resultado dos cabeçalhos, use o verificador gratuito de cabeçalhos de segurança, que roda o mesmo snapshot. Para a parte do certificado, leia o guia de certificado SSL/TLS e HSTS; o checklist de lançamento de site coloca o HSTS ao lado dos redirecionamentos, do DNS e das demais verificações antes de colocar no ar.