HTTP/2 sobre TLS é anunciado usando o identificador ALPN h2, definido pelo RFC 9113. O Google recomenda verificar ou corrigir todos os servidores, proxies e balanceadores de carga compatíveis com HTTP/2 no caminho da requisição; consulte as orientações sobre CVE-2023-44487.

Instalar um binário de release

Go não é necessário para executar a ferramenta. Baixe o arquivo para sua plataforma na última release do GitHub:

Extraia o arquivo e execute rapid-reset-check --version. No Windows, o executável é nomeado rapid-reset-check.exe.

Cada release inclui SHA256SUMS. No Linux, verifique um arquivo baixado a partir do mesmo diretório com:

No macOS, compare shasum -a 256 <arquivo> com a linha correspondente em SHA256SUMS. Os arquivos de release pública também recebem uma atestação de artefato (artifact attestation) do GitHub, que pode ser verificada com a GitHub CLI:

Compilar a partir do código-fonte

• Go 1.22 ou mais recente

Não é necessária nenhuma instalação de Node.js, cURL, nghttp2 ou WHOIS.

Builds a partir do código-fonte relatam dev em --version; builds de release recebem sua versão pela tag da release.

Início rápido

Varra apenas endpoints que você possui ou está autorizado a avaliar.

Varra um ou mais endpoints públicos:

Nomes de host simples são normalizados para HTTPS na porta 443. URLs HTTPS somente com autoridade também são aceitas:

Varra a lista de alvos JSON do repositório:

Use a entrada padrão para automação:

Execute ./rapid-reset-check --help para ver todos os limites e opções de saída.

Entrada

--input aceita o formato original de array JSON:

As formas de objeto {"urls": [...]} e {"targets": [...]} também são suportadas. Alvos posicionais e --input são intencionalmente mutuamente exclusivos. Endpoints normalizados duplicados são varridos uma única vez, e cada execução é limitada a 4.096 alvos de entrada.

Apenas endpoints HTTPS estão no escopo. Credenciais, caminhos não raiz, consultas, fragmentos, esquemas não suportados, portas malformadas e nomes de host ambíguos são rejeitados em vez de serem reescritos silenciosamente.

Avaliações

O relatório inclui cada endereço resolvido tentado, ALPN negociado, versão e cifra TLS, dados limitados de identidade/validade do certificado, tempo, decisões de política, contagens de endereços omitidos, uma flag explícita de completude e um resumo. Ele não coleta corpos de resposta, cabeçalhos de resposta, cookies ou certificados brutos.

Padrões seguros

• Certificados TLS e nomes de host são verificados. Use --ca-file para adicionar uma CA privada; não há modo de verificação inseguro.
• Endereços loopback, privados, link-local, multicast, não especificados, CGNAT, de documentação, benchmark e outros reservados são bloqueados por padrão. Use --allow-private somente para endpoints internos que você está autorizado a avaliar.
• Os resultados de DNS são fixados para cada conexão, mantendo o nome de host original para SNI e verificação de certificado.
• A concorrência de conexões, os tempos limite por endereço e os endereços por alvo são limitados.
• O scanner não tenta novamente automaticamente e não segue redirecionamentos, pois nunca envia uma requisição HTTP. Envie cada autoridade HTTPS que você precisa avaliar.

Exemplo de opções:

Para um endpoint autorizado com PKI privada:

O código de saída 0 significa que cada alvo produziu uma observação ALPN completa. O código de saída 1 significa que pelo menos um alvo foi inválido, bloqueado por política ou indeterminado; o relatório ainda é gravado. Erros de uso da CLI e de configuração retornam 2. Observar h2 não muda por si só o código de saída, pois é um sinal de inventário, não um veredito de vulnerabilidade.

Interpretando e agindo sobre os resultados

Para cada resultado h2_observed_review_required:

1. Identifique o terminador TLS visível externamente e todos os proxies, balanceadores de carga, gateways e servidores de origem compatíveis com HTTP/2 por trás dele.
2. Verifique cada produto e versão contra o aviso de CVE-2023-44487 do respectivo fornecedor.
3. Aplique as correções atuais e as orientações de reset/limitação de taxa do fornecedor.
4. Confirme que os controles de DDoS na borda protegem a origem e não podem ser contornados por meio de um nome de host, endereço ou porta alternativos.
5. Valide a configuração e o estado de correção a partir de inventário ou telemetria confiáveis. Não use o resultado de ALPN deste scanner como evidência de remediação.

Limitações

Os resultados são específicos ao nome de host, às respostas de DNS, ao caminho de rede, ao endpoint TLS e ao momento da varredura. CDNs, anycast, DNS split-horizon, balanceamento de carga, portas alternativas e endereços não testados podem produzir resultados diferentes. O scanner não:

• determina se um servidor está vulnerável, corrigido, mitigado ou seguro;
• testa o comportamento de Rapid Reset ou envia qualquer frame de reset;
• inspeciona HTTP/2 em texto claro (h2c), QUIC/HTTP/3, redirecionamentos, origens ocultas atrás de uma borda ou serviços não HTTPS;
• infere o estado de correção a partir de cabeçalhos Server falsificáveis ou impressões digitais de CDN;
• substitui a revisão de configuração, o inventário de ativos, as orientações do fornecedor ou os testes de carga autorizados em um ambiente isolado.

Desenvolvimento

A suíte de testes usa fixtures TLS locais e não varre serviços públicos.

Releases automatizadas

O Release Please gerencia as versões de release e as tags vX.Y.Z a partir de mensagens de Conventional Commit. O desenvolvimento normal não exige criar ou enviar tags:

1. Commits mesclados em main fazem o Release Please abrir ou atualizar um PR de release contendo a versão e as alterações de changelog.
2. Mesclar esse PR de release cria a tag de versão e uma release draft no GitHub.
3. O mesmo workflow testa o código-fonte da tag, faz a compilação cruzada dos seis arquivos, cria somas de verificação e proveniência, envia os assets e publica o rascunho.

Use fix: para alterações de correção, feat: para alterações menores e um marcador de mudança incompatível (!) ou rodapé BREAKING CHANGE: para alterações principais. Os mantenedores devem habilitar Settings > Actions > General > Workflow permissions > Allow GitHub Actions to create and approve pull requests uma vez para que o Release Please gerencie seu PR.

Se a publicação de assets falhar depois que o Release Please criar uma tag, a release permanece como draft. Execute novamente o workflow Release manualmente com essa tag vX.Y.Z existente após corrigir a falha. Não crie nem envie uma tag substituta.