HTTP/2 su TLS viene pubblicizzato utilizzando l'identificatore ALPN h2 definito da RFC 9113. Google consiglia di verificare o applicare patch a ogni server, proxy e load balancer compatibile con HTTP/2 nel percorso della richiesta; consulta la guida su CVE-2023-44487.

Installare un binario di release

Go non è necessario per eseguire lo strumento. Scarica l'archivio per la tua piattaforma dall'ultima release GitHub:

Estrai l'archivio, quindi esegui rapid-reset-check --version. Su Windows, l'eseguibile si chiama rapid-reset-check.exe.

Ogni release include SHA256SUMS. Su Linux, verifica un archivio scaricato dalla stessa directory con:

Su macOS, confronta shasum -a 256 <archive> con la riga corrispondente in SHA256SUMS. Gli archivi pubblicati nelle release pubbliche ricevono anche un'attestazione dell'artefatto GitHub, che può essere verificata con la GitHub CLI:

Compilare dal sorgente

• Go 1.22 o successivo

Non è richiesta alcuna installazione di Node.js, cURL, nghttp2 o WHOIS.

Le build dal sorgente riportano dev con --version; le build di release ricevono la loro versione dal tag della release.

Avvio rapido

Scansiona solo endpoint che possiedi o che sei autorizzato a valutare.

Scansiona uno o più endpoint pubblici:

I nomi host senza schema vengono normalizzati su HTTPS sulla porta 443. Sono accettati anche URL HTTPS con la sola authority:

Scansiona l'elenco di target JSON del repository:

Usa l'input standard per l'automazione:

Esegui ./rapid-reset-check --help per tutti i limiti e le opzioni di output.

Input

--input accetta il formato originale di array JSON:

Sono supportate anche le forme a oggetto {"urls": [...]} e {"targets": [...]}. I target posizionali e --input sono intenzionalmente mutuamente esclusivi. Gli endpoint normalizzati duplicati vengono scansionati una sola volta e ogni esecuzione è limitata a 4.096 target di input.

Solo gli endpoint HTTPS sono in scope. Credenziali, percorsi non root, query, frammenti, schemi non supportati, porte malformate e nomi host ambigui vengono rifiutati invece di essere riscritti silenziosamente.

Valutazioni

Il report include ogni indirizzo risolto tentato, ALPN negoziato, versione TLS e cipher, dati limitati di identità/validità del certificato, tempistiche, decisioni di policy, conteggi degli indirizzi omessi, un flag esplicito di completezza e un riepilogo. Non raccoglie body di risposta, header di risposta, cookie o certificati grezzi.

Default sicuri

• I certificati TLS e i nomi host vengono verificati. Usa --ca-file per aggiungere una CA privata; non esiste una modalità di verifica non sicura.
• Gli indirizzi loopback, privati, link-local, multicast, non specificati, CGNAT, di documentazione, benchmark e altri indirizzi riservati sono bloccati per impostazione predefinita. Usa --allow-private solo per endpoint interni che sei autorizzato a valutare.
• I risultati DNS vengono fissati per ogni connessione, mentre il nome host originale viene mantenuto per la verifica SNI e del certificato.
• La concorrenza delle connessioni, i timeout per indirizzo e gli indirizzi per target sono limitati.
• Lo scanner non ritenta automaticamente e non segue i redirect perché non invia mai una richiesta HTTP. Invia ogni authority HTTPS che devi valutare.

Opzioni di esempio:

Per un endpoint autorizzato con PKI privata:

Il codice di uscita 0 significa che ogni target ha prodotto un'osservazione ALPN completa. Il codice di uscita 1 significa che almeno un target non era valido, è stato bloccato dalla policy o è indeterminato; il report viene comunque scritto. Gli errori di utilizzo della CLI e di configurazione restituiscono 2. Osservare h2 non modifica di per sé il codice di uscita, perché è un segnale di inventario, non un verdetto di vulnerabilità.

Interpretare e agire sui risultati

Per ogni risultato h2_observed_review_required:

1. Identifica il terminatore TLS visibile esternamente e tutti i proxy, load balancer, gateway e server di origine compatibili con HTTP/2 dietro di esso.
2. Controlla ogni prodotto e versione rispetto all'avviso CVE-2023-44487 del rispettivo fornitore.
3. Applica le patch correnti e le linee guida del fornitore su reset/rate-limiting.
4. Conferma che i controlli DDoS perimetrali proteggano l'origine e non possano essere aggirati tramite un nome host, un indirizzo o una porta alternativi.
5. Valida la configurazione e lo stato delle patch da inventario o telemetria attendibili. Non utilizzare il risultato ALPN di questo scanner come prova di mitigazione.

Limitazioni

I risultati sono specifici del nome host, delle risposte DNS, del percorso di rete, dell'endpoint TLS e del momento della scansione. CDN, anycast, DNS split-horizon, load balancing, porte alternative e indirizzi non testati possono produrre risultati diversi. Lo scanner non:

• determinare se un server è vulnerabile, aggiornato, mitigato o sicuro;
• testare il comportamento di Rapid Reset o inviare frame di reset;
• ispezionare HTTP/2 in chiaro (h2c), QUIC/HTTP/3, redirect, origini nascoste dietro un edge o servizi non HTTPS;
• dedurre lo stato delle patch da header Server falsificabili o fingerprint CDN;
• sostituire la revisione della configurazione, l'inventario degli asset, le indicazioni del fornitore o i test di carico autorizzati in un ambiente isolato.

Sviluppo

La suite di test utilizza fixture TLS locali e non scansiona servizi pubblici.

Release automatizzate

Release Please gestisce le versioni delle release e i tag vX.Y.Z dai messaggi dei Conventional Commit. Lo sviluppo normale non richiede la creazione o il push di tag:

1. I commit uniti a main fanno sì che Release Please apra o aggiorni una PR di release contenente la versione e le modifiche al changelog.
2. L'unione di quella PR di release crea il tag di versione e una bozza di release GitHub.
3. Lo stesso workflow testa il sorgente taggato, esegue la cross-compilazione di tutti e sei gli archivi, crea checksum e provenance, carica gli asset e pubblica la bozza.

Usa fix: per le modifiche patch, feat: per le modifiche minori e un indicatore di breaking change (!) o il footer BREAKING CHANGE: per le modifiche maggiori. I maintainer devono abilitare una volta Settings > Actions > General > Workflow permissions > Allow GitHub Actions to create and approve pull requests affinché Release Please possa gestire la sua PR.

Se la pubblicazione degli asset fallisce dopo che Release Please ha creato un tag, la release rimane una bozza. Esegui di nuovo manualmente il workflow Release con quel tag vX.Y.Z esistente dopo aver corretto il problema. Non creare né pushare un tag sostitutivo.