10. Considerazioni sulla sicurezza (Security Considerations)
Le considerazioni sulla sicurezza di HTTP/3 dovrebbero essere paragonabili a quelle di HTTP/2 con TLS. Tuttavia, molte delle considerazioni della Sezione 10 di [HTTP/2] si applicano a [QUIC-TRANSPORT] e sono discusse in quel documento.
10.1. Autorità del server (Server Authority)
HTTP/3 si basa sulla definizione HTTP di autorità. Le considerazioni sulla sicurezza relative alla determinazione dell'autorità sono discusse nella Sezione 17.1 di [HTTP].
10.2. Attacchi cross-protocol (Cross-Protocol Attacks)
L'uso di ALPN negli handshake TLS e QUIC stabilisce il protocollo applicativo target prima che i byte del livello applicativo vengano elaborati. Questo garantisce che gli endpoint abbiano forti assicurazioni che i peer stiano utilizzando lo stesso protocollo.
Questo non garantisce la protezione da tutti gli attacchi cross-protocol. La Sezione 21.5 di [QUIC-TRANSPORT] descrive alcuni modi in cui il testo in chiaro dei pacchetti QUIC può essere utilizzato per eseguire falsificazioni di richieste contro endpoint che non utilizzano trasporti autenticati.
10.3. Attacchi di incapsulamento intermediario (Intermediary-Encapsulation Attacks)
La codifica dei campi HTTP/3 consente l'espressione di nomi che non sono nomi di campo validi nella sintassi utilizzata da HTTP (Sezione 5.1 di [HTTP]). Le richieste o risposte contenenti nomi di campo non validi DEVONO (MUST) essere trattate come malformate.
Allo stesso modo, HTTP/3 può trasportare valori di campo che non sono validi. Mentre la maggior parte dei valori che possono essere codificati non altereranno l'analisi dei campi, il ritorno a capo (ASCII 0x0d), l'avanzamento riga (ASCII 0x0a) e il carattere null (ASCII 0x00) potrebbero essere sfruttati da un attaccante se vengono tradotti letteralmente.
10.4. Cacheabilità delle risposte push (Cacheability of Pushed Responses)
Le risposte push non hanno una richiesta esplicita dal client; la richiesta è fornita dal server nel frame PUSH_PROMISE.
Quando più tenant condividono spazio sullo stesso server, quel server DEVE (MUST) garantire che i tenant non siano in grado di fare push di rappresentazioni di risorse su cui non hanno autorità.
10.5. Considerazioni sul denial-of-service (Denial-of-Service Considerations)
Una connessione HTTP/3 può richiedere un maggiore impegno di risorse per operare rispetto a una connessione HTTP/1.1 o HTTP/2.
La capacità di inviare elementi di protocollo non definiti che il peer deve ignorare può essere abusata per far sì che un peer spenda tempo di elaborazione aggiuntivo.
Un endpoint che non monitora tale comportamento si espone al rischio di attacco denial-of-service. Le implementazioni DOVREBBERO (SHOULD) tracciare l'uso di queste funzionalità e impostare limiti al loro utilizzo.
10.5.1. Limiti sulla dimensione della sezione campo (Limits on Field Section Size)
Una sezione campo di grandi dimensioni (Sezione 4.1) può far sì che un'implementazione impegni una grande quantità di stato. Un endpoint può utilizzare l'impostazione SETTINGS_MAX_FIELD_SECTION_SIZE (Sezione 4.2.2) per avvisare i peer dei limiti che potrebbero applicarsi alla dimensione delle sezioni campo.
10.5.2. Problemi CONNECT (CONNECT Issues)
Il metodo CONNECT può essere utilizzato per creare un carico sproporzionato su un proxy, poiché la creazione di flussi è relativamente poco costosa rispetto alla creazione e manutenzione di una connessione TCP.
10.6. Uso della compressione (Use of Compression)
La compressione può consentire a un attaccante di recuperare dati segreti quando vengono compressi nello stesso contesto di dati sotto il controllo dell'attaccante. HTTP/3 abilita la compressione dei campi (Sezione 4.2).
Le implementazioni che comunicano su un canale sicuro NON DEVONO (MUST NOT) comprimere contenuti che includono sia dati riservati che dati controllati dall'attaccante, a meno che non vengano utilizzati contesti di compressione separati per ciascuna fonte di dati.
10.7. Padding e analisi del traffico (Padding and Traffic Analysis)
Il padding può essere utilizzato per oscurare la dimensione esatta del contenuto del frame ed è fornito per mitigare attacchi specifici all'interno di HTTP.
10.8. Analisi dei frame (Frame Parsing)
Diversi elementi di protocollo contengono elementi di lunghezza annidati. Un'implementazione DEVE (MUST) garantire che la lunghezza di un frame corrisponda esattamente alla lunghezza dei campi che contiene.
10.9. Dati anticipati (Early Data)
L'uso di 0-RTT con HTTP/3 crea un'esposizione all'attacco di replay. Le mitigazioni anti-replay in [HTTP-REPLAY] DEVONO (MUST) essere applicate quando si utilizza HTTP/3 con 0-RTT.
10.10. Migrazione (Migration)
Alcune implementazioni HTTP utilizzano l'indirizzo client per scopi di registrazione o controllo degli accessi. Poiché l'indirizzo di un client QUIC potrebbe cambiare durante una connessione, tali implementazioni dovranno recuperare attivamente l'indirizzo corrente del client o accettare esplicitamente che l'indirizzo originale potrebbe cambiare.
10.11. Considerazioni sulla privacy (Privacy Considerations)
Diverse caratteristiche di HTTP/3 forniscono a un osservatore l'opportunità di correlare le azioni di un singolo client o server nel tempo. Queste includono il valore delle impostazioni, il timing delle reazioni agli stimoli e la gestione di qualsiasi funzionalità controllata dalle impostazioni.
La preferenza di HTTP/3 per l'utilizzo di una singola connessione QUIC consente la correlazione dell'attività di un utente su un sito.