Il problema QPACK di HTTP/3 dimostra che la velocità amplia la superficie d’attacco

E se il prossimo miglioramento delle prestazioni del web offrisse anche agli aggressori un modo più economico per costringere i server a consumare risorse? È questa la domanda scomoda alla base delle ultime segnalazioni sugli attacchi di amplificazione QPACK. HTTP/3 non presenta problemi perché la sua idea centrale sia sbagliata. In parte, i problemi derivano dal fatto che ogni ottimizzazione crea nuovo stato, nuovi livelli di traduzione e nuove ipotesi che i difensori devono comprendere.

Il problema immediato riguarda una classe di attacchi contro QPACK, il meccanismo di compressione degli header di HTTP/3. FoxIO segnala che un client remoto non autenticato può costringere un server HTTP/3 ad allocare una quantità di memoria da decine a migliaia di volte superiore al traffico inviato. È un’asimmetria allarmante, ma la lezione più ampia conta più del titolo: i protocolli moderni possono amplificare non solo il traffico di rete, ma anche il lavoro di analisi, la pressione sulla memoria e la complessità operativa.

Uno studio separato del 2026 dimostra lo stesso punto sul confine dell’infrastruttura. I ricercatori hanno individuato debolezze nella conversione da HTTP/3 a HTTP/1.1 presso sei importanti provider CDN: nella loro valutazione, tutti e sei erano vulnerabili a una variante di amplificazione della banda e cinque a una variante di amplificazione delle connessioni. I ricercatori hanno identificato 42.330 sottodomini potenzialmente vulnerabili e hanno dichiarato che due provider CDN avevano riconosciuto le vulnerabilità, assegnato ricompense per i bug e implementato misure di mitigazione, secondo lo studio. Si tratta di risultati di ricerca, non della prova che ogni implementazione di HTTP/3 sia oggi esposta; mostrano però quanto facilmente una funzionalità possa diventare una responsabilità quando i sistemi ai due lati di un gateway parlano versioni diverse del web.

HTTP/3 non ha eliminato la complessità: l’ha spostata in punti più difficili

Il fascino di HTTP/3 è reale. Funziona su QUIC anziché su TCP, combinando funzioni relative al trasporto e a TLS e supportando flussi multiplexati. Il design punta ad affrontare problemi del trasporto come il blocco head-of-line e a ridurre la latenza di connessione. Cloudflare ha osservato che HTTP/3 rappresentava il 28% del traffico monitorato a maggio 2023, rispetto a poco più del 23% a maggio 2022.

Ma le prestazioni, da sole, non sono una proprietà di sicurezza. QUIC viene generalmente eseguito nello spazio utente sopra UDP, modificando ciò che i controlli di rete tradizionali possono vedere e gestire. Senza terminazione di QUIC e TLS, i dispositivi intermedi non possono ispezionare completamente le richieste HTTP/3, gli header o la logica applicativa. Possono comunque usare indirizzi IP, porte, frequenza dei pacchetti, dimensioni dei datagrammi e schemi dei flussi, ma la visibilità consueta di uno stack incentrato su TCP non è più sufficiente.

QPACK aggiunge un ulteriore livello di stato. La compressione è utile perché gli header ripetuti non devono essere trasmessi per intero, ma le rappresentazioni compresse devono essere decodificate sulla base di strutture condivise, come le tabelle dinamiche. Se un’implementazione gestisce male i flussi bloccati o costruiti ad arte, un input di piccole dimensioni può richiedere una quantità sproporzionata di memoria o potenza di calcolo. A nostro avviso, non si tratta di una categoria di bug incidentale. È il costo prevedibile in termini di sicurezza dell’aumento di efficienza del protocollo attraverso meccanismi con stato.

Il divario più pericoloso è quello tra la progettazione del protocollo e la realtà della sua implementazione

La ricerca sulle CDN è particolarmente importante perché l’attacco non dipende solo da un difetto in una singola implementazione di server. Sfrutta una discrepanza: una connessione HTTP/3 efficiente in arrivo a una CDN può essere tradotta in traffico HTTP/1.1 meno efficiente verso un server d’origine. Il punto d’accesso comprende un modello prestazionale; il backend ne assorbe un altro.

Questo dovrebbe cambiare il modo in cui le organizzazioni valutano gli aggiornamenti dei protocolli. “Abbiamo attivato HTTP/3 sul punto d’accesso” non è una descrizione completa dell’architettura. Gli operatori devono anche chiedersi che cosa accade tra il punto d’accesso e l’origine, dove vengono espansi gli header, come vengono controllate le durate delle connessioni e quale componente gestisce i limiti di frequenza. Anche una porta d’ingresso sicura può trasformarsi in un amplificatore se il livello di traduzione viene trattato come semplice infrastruttura anziché come superficie d’attacco.

Lo stesso principio vale per QPACK. Un server può essere perfettamente raggiungibile e negoziare correttamente HTTP/3, pur presentando comportamenti pericolosi nell’uso delle risorse di fronte a sequenze di compressione insolite. I test di sicurezza devono quindi misurare più della semplice capacità di rifiutare input malformati. Devono misurare quanta memoria, CPU, capacità di connessione e traffico a valle vengono consumati prima del rifiuto.

“Basta disattivare HTTP/3” è una mitigazione, non una strategia

Gli operatori hanno un’opzione drastica: bloccare la porta UDP 443 ed eliminare HTTP/3 durante un incidente. Ma così HTTP/3 verrebbe rimosso anche per gli utenti legittimi. Controlli più mirati — limiti di frequenza, filtraggio dei pacchetti malformati, validazione della versione, validazione degli indirizzi e mitigazione a monte — possono ridurre l’esposizione senza sottrarre il protocollo a tutti.

La distinzione conta perché disattivare un protocollo può nascondere le debolezze architetturali invece di risolverle. Se l’origine non riesce a gestire il traffico tradotto, o se un’implementazione non è in grado di limitare la memoria associata a QPACK, la stessa debolezza potrebbe riapparire quando HTTP/3 verrà riattivato. La risposta giusta non è una paura permanente di QUIC; è una disciplina di implementazione che tratti l’esaurimento delle risorse come un problema di correttezza di primo livello.

Le recenti divulgazioni dovrebbero inoltre scoraggiare le classificazioni semplicistiche della gravità. Un attacco non deve essere banale per essere importante. Una tecnica che richiede conoscenze specialistiche può comunque essere preziosa per un aggressore se funziona contro un’infrastruttura condivisa, colpisce molti tenant o costringe i difensori ad adottare una risposta costosa, tutto o niente. Al contrario, un’elevata cifra teorica di amplificazione non implica automaticamente una compromissione universale. L’esposizione dipende dall’implementazione, dalla configurazione, dai controlli sul traffico e dal percorso preciso tra client, CDN e origine.

La nostra conclusione è semplice: vale ancora la pena adottare HTTP/3, ma solo dove è possibile osservare e testare l’intera catena delle risorse. Le organizzazioni dovrebbero censire ogni implementazione di QUIC e HTTP/3, rivedere i limiti di QPACK e dei flussi, testare la traduzione tra CDN e origine e assicurarsi che il monitoraggio sappia distinguere gli attacchi UDP flood dagli abusi a livello applicativo. I vincitori non saranno i team che adotteranno per primi il protocollo più recente. Saranno quelli capaci di spiegare nei dettagli che cosa il protocollo induce la loro infrastruttura a fare quando l’input è ostile.