Teste HSTS e verificação da preload list

Por que testar HSTS?

O cabeçalho HSTS é um dos controles de segurança HTTPS mais eficazes, mas costuma ser mal configurado: max-age curto demais, includeSubDomains esquecido, ou um domínio elegível para a preload list que nunca foi submetido. Testar a sua configuração regularmente ajuda a detectar essas brechas antes que sejam exploradas.

Três casos de uso principais:

• Auditoria de segurança antes da entrada em produção: validar que a cadeia HTTPS, o redirecionamento de HTTP para HTTPS e o cabeçalho Strict-Transport-Security estão coerentes antes de abrir um novo domínio ao público.
• Preparação para a preload list: verificar os quatro requisitos (max-age maior ou igual a 31536000, includeSubDomains, preload, redirecionamento HTTP para HTTPS) antes de submeter o domínio a hstspreload.org.
• Verificação pós-migração: depois de uma mudança de infraestrutura (migração para Cloudflare, mudança para um novo cluster Nginx), confirmar que o cabeçalho HSTS continua sendo enviado com as diretivas corretas no domínio raiz e nos subdomínios.

Como usar o teste HSTS em 3 passos

Passo 1: Inserir o domínio

Insira o domínio raiz sem https:// nem caminho (por exemplo, captaindns.com). A ferramenta aponta automaticamente para a versão HTTPS do site e segue o redirecionamento inicial, se houver. Evite os subdomínios na primeira análise, exceto se o seu objetivo for verificar um serviço específico (por exemplo, api.captaindns.com).

Passo 2: Iniciar o teste HSTS

Clique em Testar. O CaptainDNS executa três ações em paralelo: consulta do cabeçalho Strict-Transport-Security retornado pelo servidor, pedido à preload list do Chrome para confirmar o status e análise das diretivas max-age, includeSubDomains e preload. O resultado completo aparece em menos de 3 segundos.

Passo 3: Aplicar as recomendações

Leia o seu grau (missing, weak, good, preload-ready ou preloaded) e a lista de correções sugeridas. Copie o snippet Nginx, Apache ou Cloudflare adequado à sua stack, faça o deploy e execute o teste de novo para confirmar a passagem ao grau superior. Itere até alcançar preloaded se a preload list for seu objetivo.

O que é HSTS?

HSTS (HTTP Strict Transport Security) é um cabeçalho de resposta HTTP padronizado pelo RFC 6797 em 2012. Quando um navegador recebe esse cabeçalho numa conexão HTTPS válida, ele memoriza o domínio e recusa, pelo tempo definido, qualquer conexão em texto claro com esse domínio. A conversão de http:// para https:// é feita localmente pelo navegador, antes de qualquer pacote de rede, eliminando a janela de interceptação durante o primeiro redirecionamento.

O cabeçalho é composto por três diretivas:

• max-age: tempo em segundos durante o qual o navegador aplica HSTS. Valor recomendado para produção estável: 31536000 (1 ano). Para a preload list: mínimo 31536000.
• includeSubDomains: estende a proteção a todos os subdomínios (www, api, mail etc.). Obrigatória para a preload list.
• preload: indica o consentimento do dono para a submissão do domínio à preload list do Chrome. Sem essa diretiva, hstspreload.org recusa a submissão.

Exemplo de cabeçalho completo:

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

Sem HSTS, um usuário que escreve captaindns.com na barra de endereço envia primeiro um pedido HTTP em texto claro. Um atacante na mesma rede Wi-Fi pode interceptar esse pedido e servir uma versão pirata do site (ataque SSL stripping). O HSTS torna esse ataque impossível depois da primeira visita legítima, e a preload list o torna impossível desde a primeira visita para os domínios pré-carregados no navegador.

Os 5 graus explicados

O CaptainDNS atribui um grau com base nas diretivas detectadas e no status preload. Veja a grade de avaliação:

O grau preload-ready não significa que o domínio está na preload list: ele apenas indica que o domínio cumpre as condições técnicas para ser submetido. A submissão em si é feita em hstspreload.org e a inclusão no Chrome geralmente leva de 6 a 12 semanas.

Como corrigir sua configuração HSTS

Aqui estão os snippets prontos para colar para as três plataformas mais comuns. Todos ativam um HSTS em conformidade com os requisitos da preload list.

Nginx

# /etc/nginx/sites-available/captaindns.com
server {
    listen 443 ssl http2;
    server_name captaindns.com;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

A palavra-chave always garante que o cabeçalho seja enviado mesmo nas respostas de erro (4xx, 5xx). Sem essa palavra-chave, uma página 404 não levaria o cabeçalho HSTS.

Apache (mod_headers)

# /etc/apache2/sites-available/captaindns.com.conf
<VirtualHost *:443>
    ServerName captaindns.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Ative o módulo com a2enmod headers se ainda não estiver ativado, depois recarregue o Apache.

Cloudflare Workers

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    const response = await fetch(request);
    const newHeaders = new Headers(response.headers);
    newHeaders.set(
        'Strict-Transport-Security',
        'max-age=31536000; includeSubDomains; preload'
    );
    return new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: newHeaders,
    });
}

No Cloudflare, você também pode ativar o HSTS pelo painel (SSL/TLS, Edge Certificates, HTTP Strict Transport Security) sem implementar um Worker.

Após cada mudança, execute o teste HSTS de novo para confirmar a aplicação no CDN ou no reverse proxy.

Inscrever-se na preload list do HSTS

A preload list é uma lista de domínios codificada de forma estática no Chrome (e reaproveitada por Firefox, Safari, Edge e Opera). Qualquer domínio presente na lista é tratado como HTTPS-only pelos navegadores desde a primeira visita, sem nem precisar receber o cabeçalho HSTS antes.

Para submeter um domínio em hstspreload.org, é preciso cumprir quatro condições:

• max-age maior ou igual a 31536000 (1 ano).
• Diretiva includeSubDomains presente no cabeçalho.
• Diretiva preload presente no cabeçalho.
• Redirecionamento HTTP para HTTPS ativo no domínio raiz e em todos os subdomínios.

O certificado também precisa ser válido (cadeia completa, não autoassinado, não expirado). Uma vez aceita a submissão, a inclusão no Chrome leva em média de 6 a 12 semanas, o tempo para a mudança ser publicada numa nova versão estável do navegador.

Aviso sobre a irreversibilidade. A retirada de um domínio da preload list é tecnicamente possível (formulário de remoção em hstspreload.org), mas leva vários meses e só se aplica às versões futuras do Chrome. Os usuários em versões antigas continuarão forçando o HTTPS por anos. Antes de submeter, verifique se cada subdomínio de produção, de staging e de administração interna está acessível em HTTPS, e se não tem um plano de migração para outro nome de domínio no curto prazo.

Casos de uso reais

Incidente 1: grau weak após uma auditoria ANSSI

Sintoma: uma auditoria ANSSI aponta que captaindns.com envia um cabeçalho HSTS, mas que o valor de max-age (3600) é baixo demais para oferecer uma proteção real.

Diagnóstico: o teste HSTS confirma a presença do cabeçalho Strict-Transport-Security: max-age=3600. Nenhuma diretiva includeSubDomains nem preload. O grau atribuído é weak.

Ação: alterar a configuração do Nginx para max-age=31536000; includeSubDomains; preload, depois de validar que todos os subdomínios (api, mail, status) respondem em HTTPS. Executar o teste de novo: o grau passa para preload-ready.

Incidente 2: subdomínio quebrado após ativação de includeSubDomains

Sintoma: após a ativação de includeSubDomains em captaindns.com, a ferramenta interna metrics.captaindns.com fica inacessível para as equipes. Erro "ERR_SSL_PROTOCOL_ERROR" no Chrome.

Diagnóstico: o subdomínio metrics dispõe apenas de um endpoint HTTP. A diretiva includeSubDomains, memorizada pelos navegadores das equipes, agora força o HTTPS, mas nenhum certificado é servido nesse subdomínio.

Ação: instalar com urgência um certificado Let's Encrypt em metrics, ou retirar temporariamente a diretiva includeSubDomains e limpar o cache HSTS local das equipes (chrome://net-internals/#hsts) o tempo necessário para colocar o subdomínio em conformidade.

Incidente 3: domínio preload-ready nunca submetido

Sintoma: durante uma auditoria de segurança interna, o teste revela que captaindns.com está preload-ready há mais de um ano, mas não consta na preload list do Chrome. Os novos visitantes seguem vulneráveis ao SSL stripping na primeira visita.

Diagnóstico: a configuração do servidor está correta (max-age=31536000, includeSubDomains, preload, redirecionamento HTTP para HTTPS). O status preload retornado pelo Chrome é "Not in preload list".

Ação: submeter o domínio em hstspreload.org. Acompanhar a confirmação e depois esperar de 6 a 12 semanas para a propagação na versão estável do Chrome. Documentar a decisão e a sua irreversibilidade no registro interno de segurança.

FAQ - Perguntas frequentes

P: O que é HSTS?

R: HSTS (HTTP Strict Transport Security) é um cabeçalho HTTP de resposta definido pelo RFC 6797. Ele indica ao navegador para contatar o domínio apenas em HTTPS pelo tempo definido por max-age. Uma vez memorizado o cabeçalho, o navegador converte qualquer pedido http:// em https:// antes do envio, o que impede o downgrade e os ataques de SSL stripping em redes não confiáveis.

P: Qual valor de max-age escolher para HSTS?

R: Para uma entrada em produção cautelosa, comece com max-age=300 (5 minutos) para testar sem compromisso. Uma vez validada a cadeia HTTPS, suba progressivamente para 86400 (1 dia) e depois 604800 (1 semana). Para a preload list, o valor mínimo exigido é 31536000 (1 ano), que também é o valor recomendado em produção estável. Um valor mais alto não traz nenhum ganho adicional.

P: O preload HSTS é reversível?

R: Sim, mas na prática de forma muito lenta. Você pode pedir a remoção em hstspreload.org, mas a operação leva vários meses e só se aplica às versões futuras do Chrome. Os usuários em versões antigas continuarão forçando o HTTPS por anos. Antes de submeter um domínio, certifique-se de que todos os recursos, incluindo subdomínios internos, estejam acessíveis em HTTPS.

P: O HSTS funciona sem HTTPS?

R: Não. O RFC 6797 exige que o cabeçalho Strict-Transport-Security seja ignorado quando recebido via HTTP. Apenas as respostas servidas numa conexão TLS válida podem ativar o HSTS no navegador. É preciso, portanto, instalar primeiro um certificado válido (Let's Encrypt, por exemplo) e redirecionar todo o tráfego HTTP para HTTPS antes de enviar o cabeçalho.

P: HSTS e redirecionamento HTTPS, qual a diferença?

R: Um redirecionamento 301 de HTTP para HTTPS é executado pelo servidor depois de o pedido em texto claro já ter saído do dispositivo. Um atacante em posição de man-in-the-middle pode interceptar esse primeiro pedido. O HSTS resolve o problema: depois da primeira visita, o próprio navegador converte http:// em https:// antes de qualquer envio na rede. O redirecionamento continua necessário para a primeira visita e para os clientes que nunca receberam o cabeçalho.

P: É preciso ativar includeSubDomains?

R: Sim, assim que todos os subdomínios (www, api, mail, admin, intranet etc.) estiverem acessíveis em HTTPS. A diretiva includeSubDomains estende a proteção HSTS para todo o domínio e é obrigatória para a preload list. Antes de ativá-la, audite cada subdomínio ativo: um subdomínio interno em HTTP (por exemplo, uma ferramenta de monitoramento) ficará inacessível assim que os navegadores memorizarem o cabeçalho.

Ferramentas complementares

O teste HSTS combina-se com outras ferramentas CaptainDNS para cobrir a segurança HTTP, DNS e e-mail:

Recursos úteis

• Guia completo de HSTS e preload list da CaptainDNS (guia de referência para ativar o Strict-Transport-Security passo a passo: diretivas, configurações de Nginx, Apache, Cloudflare, AWS, Caddy, submissão à preload list)
• hstspreload.org (formulário oficial de submissão à preload list do Chrome)
• MDN: Strict-Transport-Security (documentação de referência sobre o cabeçalho HSTS e suas diretivas)
• RFC 6797 (especificação original do HTTP Strict Transport Security)
• OWASP HSTS Cheat Sheet (boas práticas de implementação do HSTS)
• content-security-policy.com (guia prático sobre HSTS e exemplos de configuração)