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 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

Digite 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 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, requisição à 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 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 rode 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 em uma 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 do menor 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 digita captaindns.com na barra de endereço envia primeiro uma requisição HTTP em texto claro. Um atacante na mesma rede Wi-Fi pode interceptar essa requisição 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 conforme aos 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 implantar um Worker.

Após cada mudança, rode 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, ele precisa atender a 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 em uma 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 você não tem 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. Rodar 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 os times. 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 dos times, agora força o HTTPS, mas nenhum certificado é servido nesse subdomínio.

Ação: implantar com urgência um certificado Let's Encrypt em metrics, ou retirar temporariamente a diretiva includeSubDomains e limpar o cache HSTS local dos times (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 requisição 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 em uma conexão TLS válida podem ativar o HSTS no navegador. Você precisa, portanto, primeiro implantar 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 que a requisição em texto claro já saiu do dispositivo. Um atacante em posição de man-in-the-middle pode interceptar essa primeira requisição. 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 implantação do HSTS)
• content-security-policy.com (guia prático sobre HSTS e exemplos de configuração)