Auditoria de configuração HTTPS

Cole os cabeçalhos de resposta de um site — e, se os tiver, o seu certificado, um excerto do código-fonte da página e o nome de máquina — e esta página reporta como está configurada a parte HTTPS: se o HSTS está definido e durante quanto tempo, se uma política de conteúdo atualiza pedidos inseguros, se os cookies estão marcados com Secure e SameSite, se um banner de servidor revela uma versão, e o que os cabeçalhos de proxy dizem sobre o pedido que a aplicação realmente viu. O certificado é auditado no mesmo relatório, os subrecursos http:// simples são contados a partir do código-fonte da página, e os comandos que conseguem ver o handshake são listados para executar por si. Tudo corre no seu navegador e a página não faz nenhum pedido próprio.
1. Cabeçalhos de resposta
O bloco completo de cabeçalhos de resposta, incluindo a linha de estado. A fonte mais fácil: curl -sI https://example.com/ num terminal, ou o painel Cabeçalhos do separador Rede das ferramentas de desenvolvimento do navegador, copiado do início do ficheiro. Os cabeçalhos extra são lidos e ignorados; só são reportados os relacionados com HTTPS.
2. Certificado ou cadeia (opcional)
Com isto preenchido, o mesmo relatório também inclui a auditoria completa do certificado, para que configuração e certificado sejam lidos em conjunto. PEM, um corpo simples em base64 ou hexadecimal e um .p7b PKCS#7 funcionam todos; o verificador de certificados analisa o certificado por si só em mais profundidade.
3. Excerto do código-fonte da página (opcional)
Cole o código-fonte da página (ou apenas as etiquetas com URLs) e cada endereço http:// simples é listado, porque um subrecurso carregado por HTTP quebra o cadeado e pode ser reescrito em trânsito, mesmo quando a própria página chegou por HTTPS. Os endereços para o próprio host do site são assinalados à parte, já que são esses que um URL relativo corrigiria.
4. Nome de máquina (opcional)
Com um nome de máquina aqui, a auditoria verifica os nomes alternativos do assunto da mesma forma que um navegador, incluindo as regras de curinga, e compara os endereços http:// simples com eles.
nada auditado ainda
O exemplo é deliberadamente imperfeito, para que cada parte do relatório tenha algo: um bloco de cabeçalhos com HSTS e uma política de conteúdo (mas sem preload e com um cookie sem SameSite), uma cadeia de dois certificados, e um excerto de página que carrega um script por http:// simples e aponta uma imagem para o próprio host do site da mesma forma. Espere um F no exemplo e leia as conclusões por baixo para perceber o que significa cada uma.
O que é verificado. A partir do bloco de cabeçalhos: HSTS, o seu max-age, includeSubDomains e preload; uma política de conteúdo que atualiza pedidos inseguros; as flags Secure, HttpOnly e SameSite em cada Set-Cookie; um banner de servidor que indica um produto e uma versão; e os cabeçalhos encaminhados que lhe dizem se a aplicação viu o pedido como HTTPS. A partir do bloco do certificado: a auditoria completa do certificado, até verificar se cada ligação da cadeia assinou realmente a seguinte. A partir do excerto de código-fonte: os subrecursos http:// simples. Os três são reportados em separado e depois resumidos em conjunto, porque um cadeado partido costuma ser um desses três e não os outros dois. Para a lista OWASP completa de cabeçalhos de resposta de segurança — X-Content-Type-Options, proteção contra enquadramento, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP e a pontuação graduada — cole o mesmo bloco de cabeçalhos na página Verificação de cabeçalhos de segurança; as duas páginas dividem o trabalho entre a camada TLS e a camada dos cabeçalhos.

O que não consegue ver. Esta página nunca abre uma ligação TLS. Os navegadores não expõem o handshake a uma página, por isso a versão do protocolo, o conjunto de cifras, o grupo de troca de chaves, o agrafo OCSP, a retoma de sessão, o 0-RTT, a cadeia de certificados que um servidor em produção realmente envia, e se um redirecionamento de HTTP para HTTPS acontece na origem ou num proxy, estão todos fora do que qualquer página web consegue reportar. Também não consegue ir a um site de terceiros recolher os cabeçalhos por si, e não consegue dizer se um certificado é de confiança, porque isso depende de um repositório de raízes que uma página não consegue ler. Os comandos mais abaixo nesta página veem essas coisas e são para ser executados por si, na sua própria máquina.

Onde obter o bloco de cabeçalhos. Num terminal, curl -sI https://example.com/ mostra exatamente o que esta página pede. Num navegador, abra as ferramentas de desenvolvimento, vá ao separador Rede, recarregue a página, selecione o pedido do documento e copie a área completa dos cabeçalhos de resposta, ou use Copiar → Copiar cabeçalhos de resposta. Para a verificação de redirecionamento, execute também curl -sI http://example.com/ e cole os dois blocos; a página reporta-os um a seguir ao outro.
Relatório de auditoria
Nada auditado ainda. Cole um bloco de cabeçalhos acima e prima Auditar esta configuração para o relatório completo; um certificado, um excerto do código-fonte da página e um nome de máquina são opcionais, e cada um acrescenta a sua própria secção.
Teste de acessibilidade — a única parte desta página que usa a rede
Uma página não consegue abrir uma ligação TLS, mas consegue tentar um pedido comum. Se o site permitir leituras de origem cruzada, o URL onde a resposta acaba mostra se http:// foi redirecionado para https://, e isso é tudo o que isto consegue provar. Se o pedido falhar, esta página não consegue dizer se a máquina está em baixo, se a sua própria ligação está em baixo, ou se o site simplesmente não permite leituras de origem cruzada — a última é o caso comum, porque a maioria dos sites não envia Access-Control-Allow-Origin. Um URL http:// é respondido antes de qualquer redirecionamento, por isso esta é a única coisa aqui que um navegador tenta numa ligação simples. Nada sai do navegador até premir o botão.
Comandos que veem o handshake
curl -sI https://example.com/ # the header block this page reads curl -sI http://example.com/ # is plain HTTP answered, or redirected? curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/ openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName nmap --script ssl-enum-ciphers -p 443 example.com testssl.sh example.com # or: docker run --rm -ti drwetter/testssl.sh example.com
Estes comandos devem ser executados por si, numa máquina que controle, contra um host que tenha autorização para testar. A saída de -showcerts pode ser colada diretamente no verificador de certificados, e a saída dos cabeçalhos de volta nesta página.
O certificado é um documento público. Todos os certificados com confiança pública são publicados em registos de Certificate Transparency, por isso qualquer nome de máquina dentro de um deles — incluindo um nome interno ou com erros de digitação que uma autoridade de certificação pública assinou — pode ser encontrado pesquisando esses registos. Um certificado também traz os endereços de revogação que a sua entidade emissora escolheu, e esses por vezes nomeiam uma máquina interna. É por isso que o certificado que uma CDN serve não diz nada sobre o servidor de origem: os nomes nele pertencem à CDN. Se a auditoria revelar um nome de máquina que não esperava, trate-o como público e substitua o que quer que ele proteja.

Privacidade: o bloco de cabeçalhos, o certificado e o código-fonte da página são lidos localmente e nunca são enviados, e nenhum pedido de qualquer tipo é feito, a menos que prima o botão da sonda de acessibilidade. Para criar um certificado seu, use o gerador de certificados autoassinados; para verificar que uma chave privada pertence a um certificado, use o comparador de certificado e chave.