QUIC Cos'è,HTTP/3, 0-RTT e blind spot nel pentesting

QUIC è il protocollo di trasporto che alimenta HTTP/3. Capire cos’è QUIC e come funziona il suo 0-RTT handshake è fondamentale per chi fa pentesting su infrastrutture web moderne: QUIC bypassa molti tool di inspection e logging tradizionali, usa UDP invece di TCP rendendo invisibili le connessioni agli IDS che analizzano solo flussi TCP, e introduce nuove superfici di attacco legate alla sua integrazione nativa con TLS 1.3.

Cos’è QUIC #

QUIC è un protocollo di trasporto sviluppato originariamente da Google e poi standardizzato dall’IETF nell’RFC 9000 del 2021. Sostituisce TCP+TLS come trasporto per HTTP/3 (RFC 9114), costruendo tutto sopra UDP.

Il nome originale era un acronimo (Quick UDP Internet Connections) ma la versione IETF non lo usa più — è semplicemente “QUIC”.

QUIC integra nativamente in un unico protocollo:

Trasporto affidabile: come TCP, con ACK, ritrasmissioni, controllo del flusso
Cifratura: TLS 1.3 integrato nel protocollo, non sopra
Multiplexing senza head-of-line blocking: più stream indipendenti
0-RTT connection resumption: riconnessione senza handshake aggiuntivo
Connection migration: cambio di IP/porta senza interruzione della connessione

Opera su UDP, tipicamente su porta 443 (stessa di HTTPS).

Come funziona QUIC #

Integrazione con TLS 1.3 #

La differenza fondamentale rispetto a TCP+TLS è che QUIC non è “TLS sopra un trasporto”: TLS 1.3 è integrato nel protocollo QUIC a livello di design. I messaggi di handshake TLS viaggiano in QUIC CRYPTO frame invece che in un canale TCP separato.

Questo significa:

La cifratura inizia prima in QUIC che in TCP+TLS
Gli header di trasporto (dopo l’initial packet) sono parzialmente cifrati
Non è possibile fare TLS inspection tradizionale senza decifrazione attiva

Il QUIC Handshake (1-RTT) #

text

Client                              Server
  |                                    |
  |--- Initial Packet              --> |  Client Hello (TLS dentro QUIC)
  |    (parzialmente non cifrato)      |
  |                                    |
  |<-- Initial Packet (Server Hello)-- |
  |<-- Handshake Packet           ---- |  Cert, CertVerify, Finished
  |                                    |
  |--- Handshake Packet           --> |  Client Finished
  |                                    |
  |<-- 1-RTT Packet               ---- |  Dati applicativi
  |--- 1-RTT Packet               --> |
  |                                    |
  |   === CONNESSIONE QUIC ===        |

Il handshake completo richiede 1 RTT prima di poter inviare dati applicativi — uguale a TLS 1.3 su TCP.

0-RTT: Zero Round Trip Time Resumption #

Se client e server si sono già connessi in precedenza, QUIC permette di inviare dati applicativi immediatamente nel primo pacchetto, senza aspettare il completamento dell’handshake:

text

Client                              Server
  |                                    |
  |--- Initial + 0-RTT data       --> |  Invia dati subito
  |                                    |
  |<-- Initial + 1-RTT data       ---- |  Server risponde

Vantaggio: latenza ridotta per connessioni ripetute (es. ricaricamento pagina web). Svantaggio di sicurezza: i dati 0-RTT sono replay-able. Un attaccante che cattura un 0-RTT packet può ri-inviarlo al server, che potrebbe processarlo di nuovo.

Stream multiplexing senza HOL blocking #

Come SCTP e a differenza di TCP, QUIC permette più stream indipendenti in una singola connessione. Un pacchetto perso blocca solo lo stream a cui appartiene, non tutti gli altri.

In HTTP/3, ogni request/response è uno stream QUIC separato — eliminando il problema di head-of-line blocking di HTTP/2 su TCP.

Connection ID e migration #

Ogni connessione QUIC è identificata da un Connection ID scelto dal server, non dalla coppia IP:porta come TCP. Questo permette:

Connection migration: se il client cambia IP (es. da WiFi a 4G), la connessione QUIC continua usando il nuovo IP con lo stesso Connection ID
NAT rebinding trasparente: cambio di porta NAT senza interruzione

Dal punto di vista del pentester, il Connection ID è presente negli header QUIC e permette il tracking delle sessioni anche attraverso cambi di IP.

Header cifrati #

Dopo l’Initial packet, quasi tutti i field degli header QUIC sono cifrati. Solo il Connection ID e alcuni bit di flag sono visibili. Questo rende l’analisi del traffico QUIC significativamente più difficile rispetto a TCP+TLS dove almeno gli header TCP (numeri di porta, sequenza) sono in chiaro.

Dove viene usato QUIC nelle reti #

QUIC è in rapida espansione:

HTTP/3: tutti i principali siti web (Google, Cloudflare, Meta, YouTube) supportano HTTP/3 su QUIC
Chrome e Firefox: abilitano QUIC/HTTP/3 di default
Cloudflare CDN: tutto il traffico servito da Cloudflare può usare QUIC
Google services: Gmail, YouTube, Google Search usano QUIC nativamente
QUIC per non-web: nascenti implementazioni per DNS over QUIC (DoQ, RFC 9250), SMB over QUIC (Windows 11/Server 2022)

La percentuale di traffico Internet su QUIC è in costante crescita — stime recenti indicano oltre il 25% del traffico web globale.

Perché QUIC è importante in cybersecurity #

QUIC pone sfide significative per i sistemi di sicurezza tradizionali:

Invisibilità agli IDS TCP-based: la maggior parte delle signature IDS/IPS è basata su pattern di traffico TCP. Il traffico QUIC su UDP 443 può apparire come semplice traffico UDP cifrato e non triggerare nessuna rule.

Bypass di DPI: i sistemi di Deep Packet Inspection che fanno SSL inspection su TCP non vedono il traffico QUIC a meno di avere supporto esplicito per QUIC decryption.

Firewall che bloccano UDP 443: molte organizzazioni bloccano UDP 443 per forzare il fallback a TCP+TLS (che è ispezionabile). I client QUIC fanno fallback automatico a HTTP/2 su TCP quando QUIC è bloccato.

0-RTT replay attacks: dati 0-RTT non sono protetti contro replay. Operazioni non-idempotenti (POST, pagamenti, azioni irreversibili) non dovrebbero mai essere processate su 0-RTT senza protezioni applicative.

Per TLS 1.3 integrato in QUIC, vedi TLS/SSL. Per UDP su cui opera, vedi UDP.

QUIC in un engagement di pentesting #

Identificare QUIC nel traffico #

QUIC usa UDP porta 443. Il modo più semplice per identificarlo:

bash

# Catturare traffico UDP 443
tcpdump -i eth0 -nn udp port 443

# In Wireshark
udp.port == 443

Wireshark decodifica QUIC automaticamente se riconosce il pattern dei pacchetti Initial. Il filtro specifico:

text

quic
quic.version               # Versione QUIC (0x00000001 = QUIC v1)
quic.connection_id         # Connection ID

Verificare supporto HTTP/3 su un target #

bash

# Con curl (richiede build con HTTP/3 support)
curl --http3 https://target.com -v

# Alternativa: controllare header Alt-Svc
curl -I https://target.com | grep -i alt-svc
# Alt-Svc: h3=":443"; ma=86400  → supporta HTTP/3

Testare la vulnerabilità 0-RTT #

bash

# Con quiche (libreria QUIC di Cloudflare)
quiche-client --no-verify https://target.com

# Verificare se il server accetta 0-RTT
# (richiede tool specifici o implementazione custom con scapy-quic)

Bypass di inspection tramite QUIC #

In ambienti dove il traffico HTTPS TCP è inspezionato da un proxy SSL ma UDP 443 non è filtrato:

bash

# Verificare se QUIC passa dove HTTPS TCP è inspezionato
# Usare curl con HTTP/3 force
curl --http3-only https://external-target.com

Se il traffico QUIC non passa per il proxy, la comunicazione non è ispezionata — potenziale canale di bypass per exfiltration o C2.

Analisi del traffico QUIC con chiavi di sessione #

Come per TLS, con il file SSLKEYLOGFILE è possibile decifrare il traffico QUIC in Wireshark:

bash

SSLKEYLOGFILE=~/quic_keys.log curl --http3 https://target.com

In Wireshark:

Edit → Preferences → Protocols → TLS → Pre-Master-Secret log file
Selezionare il file generato

Attacchi e abusi possibili su QUIC #

0-RTT Replay Attack #

I dati inviati in 0-RTT possono essere catturati e ri-inviati al server. Se il server processa richieste non-idempotenti su 0-RTT senza protezioni, l’attacco è efficace:

text

1. Attaccante cattura un 0-RTT packet con una richiesta POST (es. acquisto)
2. Ri-invia il packet verso il server
3. Il server processa la richiesta una seconda volta

RFC 9000 raccomanda di non processare richieste non-idempotenti su 0-RTT, ma l’implementazione è responsabilità dell’applicazione.

Connection ID Tracking #

Il Connection ID, pur cambiando periodicamente in QUIC v1 per proteggere la privacy, può essere usato per tracciare sessioni durante la loro durata. In ambienti di monitoring, collegare i Connection ID alle identità degli utenti è possibile con log di rete.

Amplification Attack su QUIC #

Come altri protocolli UDP, QUIC può essere usato per amplificazione se il server risponde con Initial Retry packets di dimensioni maggiori delle richieste. RFC 9000 mitiga questo limitando la dimensione dei response packets iniziali.

DoS tramite flood di Initial packets #

Inviare massivamente QUIC Initial packets con Connection ID casuali può esaurire le risorse del server QUIC se non implementa rate limiting adeguato.

Esempi pratici con QUIC in laboratorio #

Setup con nginx e HTTP/3 #

nginx

server {
    listen 443 quic reuseport;
    listen 443 ssl;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Test con quiche-client #

bash

# Installare quiche
git clone https://github.com/cloudflare/quiche
cd quiche && cargo build --examples

# Test HTTP/3
./target/debug/examples/http3-client https://target.com

Filtrare e analizzare QUIC con tshark #

bash

tshark -i eth0 -f "udp port 443" -Y "quic" -T fields \
  -e quic.version \
  -e quic.connection_id \
  -e quic.packet_type

Detection e difesa QUIC #

Bloccare UDP 443 per forzare fallback a TCP+TLS inspezionabile — soluzione comune in ambienti enterprise con SSL inspection
Supporto QUIC nei firewall di nuova generazione: i NGFW moderni (Palo Alto, Fortinet, CheckPoint) stanno aggiungendo supporto per QUIC inspection
Monitorare Alt-Svc nei response header: indicatore che un server annuncia supporto HTTP/3
Log di flusso UDP 443: monitorare il volume per rilevare canali QUIC anomali
Protezioni 0-RTT lato applicazione: non processare operazioni non-idempotenti su early data

Hardening QUIC #

Disabilitare 0-RTT se non necessario #

nginx

# Nginx
ssl_early_data off;

Se il guadagno di latenza non è critico, disabilitare 0-RTT elimina il rischio di replay attack.

Limitare QUIC alle origini autorizzate #

bash

# iptables — permettere QUIC solo da IP autorizzati
iptables -A INPUT -p udp --dport 443 -s <trusted_range> -j ACCEPT
iptables -A INPUT -p udp --dport 443 -j DROP

Aggiornare le implementazioni QUIC #

Le librerie QUIC (quiche, ngtcp2, msquic, quic-go) hanno avuto CVE. Mantenere le versioni aggiornate è essenziale, specialmente nelle prime versioni del protocollo.

Errori comuni su QUIC #

“QUIC è sicuro perché è cifrato” La cifratura protegge la confidenzialità ma non elimina le vulnerabilità applicative. 0-RTT replay, amplification, e flood attack non richiedono di decifrare il traffico.

“Bloccare UDP 443 risolve il problema QUIC” Risolve l’inspection gap nel perimetro, ma i client faranno fallback automatico a HTTP/2 su TCP — non è un blocco definitivo di HTTP/3, solo un degradamento.

“QUIC è solo per i browser” No. SMB over QUIC è disponibile in Windows 11 e Server 2022. DNS over QUIC (DoQ) è in crescita. QUIC sta diventando un trasporto general-purpose.

“Se vedo UDP 443, è sicuramente QUIC” Non necessariamente. UDP 443 può essere usato da altri protocolli. Verificare il pattern dei pacchetti Initial con Wireshark per confermare che sia effettivamente QUIC.

FAQ su QUIC #

Cos’è QUIC e come si differenzia da TCP? QUIC è un protocollo di trasporto basato su UDP che integra nativamente TLS 1.3, multiplexing di stream, 0-RTT resumption, e connection migration. A differenza di TCP, non ha head-of-line blocking tra stream diversi e la cifratura è integrata nel protocollo stesso.

Perché QUIC usa UDP invece di TCP? UDP offre più flessibilità per implementare meccanismi di trasporto personalizzati. TCP è implementato nel kernel OS e non modificabile facilmente; costruire QUIC su UDP permette di aggiornare il protocollo di trasporto come software applicativo senza modifiche al kernel.

Cos’è la 0-RTT resumption di QUIC? È il meccanismo che permette a un client di inviare dati applicativi immediatamente nella prima richiesta verso un server conosciuto, senza aspettare il completamento dell’handshake TLS. Riduce la latenza ma i dati 0-RTT sono vulnerabili a replay attack.

Come si identifica il traffico QUIC? Con Wireshark filtrando quic o monitorando UDP porta 443 con tcpdump. Il campo Alt-Svc nei response header HTTP indica se un server supporta HTTP/3 su QUIC.

I firewall tradizionali bloccano QUIC? Dipende dalla configurazione. I firewall che bloccano esplicitamente UDP 443 bloccano QUIC. I firewall configurati solo per TCP/IP non vedono QUIC come traffico separato.

Conclusione su QUIC #

QUIC rappresenta un cambio di paradigma nel trasporto di rete: TLS integrato, UDP come base, 0-RTT, connection migration. Per i defender, introduce sfide significative di inspection e monitoring. Per gli attaccanti, è un potenziale canale di bypass in ambienti dove solo TCP è inspezionato.

La tendenza è chiara: QUIC diventerà sempre più diffuso non solo nel web ma come trasporto general-purpose. Chi lavora in sicurezza offensiva e difensiva deve capirne le implicazioni prima che diventi dominante.

Approfondisci i protocolli correlati:

Riferimento ufficiale: RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport

QUIC sta cambiando il modo in cui si analizza il traffico di rete. Se vuoi un assessment aggiornato alle tecnologie moderne: hackita.it/servizi

HackITA resta aggiornato per te. Se lo usi, considera di supportarlo: hackita.it/supporto