10. Considerazioni sulla sicurezza
Le considerazioni di sicurezza per 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
HTTP/3 si basa sulla definizione di autorità di HTTP. Le considerazioni sulla sicurezza per stabilire l'autorità sono trattate nella Sezione 17.1 di [HTTP].
10.2. Attacchi tra protocolli
L'uso di ALPN nell'handshake TLS e QUIC stabilisce il protocollo applicativo previsto prima dell'elaborazione dei byte del livello applicativo. Questo fornisce agli endpoint una forte garanzia che il pari stia usando lo stesso protocollo.
Ciò non garantisce la prevenzione di tutti gli attacchi tra protocolli. La Sezione 21.5 di [QUIC-TRANSPORT] descrive alcuni modi in cui il testo in chiaro dei pacchetti QUIC può essere usato per eseguire falsificazioni di richieste contro endpoint che non usano un trasporto autenticato.
10.3. Attacchi di incapsulamento tramite intermediari
La codifica dei campi di HTTP/3 consente di esprimere nomi di campo non validi nella sintassi usata da HTTP (vedere la Sezione 5.1 di [HTTP]). Le richieste o le risposte che contengono nomi di campo non validi DEVONO essere considerate malformate.
Analogamente, HTTP/3 può trasportare valori di campo non validi. Sebbene la maggior parte dei valori codificabili non alteri l'analisi dei campi, il ritorno a capo (ASCII 0x0d), la nuova riga (ASCII 0x0a) e il carattere nullo (ASCII 0x00), se convertiti letteralmente, possono essere sfruttati da un attaccante.
10.4. Memorizzabilità nella cache delle risposte push
Le risposte push non hanno una richiesta esplicita dal client; la richiesta è fornita dal server nel frame PUSH_PROMISE.
Quando più tenant condividono lo spazio sullo stesso server, il server DEVE assicurare che un tenant non possa inviare tramite push una rappresentazione di una risorsa per la quale non dispone dell'autorizzazione.
10.5. Considerazioni sulla negazione del servizio
Una connessione HTTP/3 può richiedere per il suo funzionamento un maggiore impegno di risorse rispetto a una connessione HTTP/1.1 o HTTP/2.
La possibilità di inviare elementi di protocollo non definiti che il pari deve ignorare può essere abusata, inducendo il pari a impiegare ulteriore tempo di elaborazione.
Gli endpoint che non monitorano tale comportamento si espongono al rischio di attacchi di negazione del servizio. Le implementazioni DOVREBBERO tenere traccia dell'uso di queste funzionalità e fissarne limiti d'uso.
10.5.1. Limiti sulla dimensione della sezione dei campi
Sezioni di campi di grandi dimensioni (Sezione 4.1) possono costringere un'implementazione a impegnare una grande quantità di stato. Un endpoint può usare l'impostazione SETTINGS_MAX_FIELD_SECTION_SIZE (Sezione 4.2.2) per comunicare al pari un limite che potrebbe essere applicato alla dimensione della sezione dei campi.
10.5.2. Problemi relativi a CONNECT
Il metodo CONNECT può essere usato per creare un carico sproporzionato su un proxy, poiché la creazione di stream è relativamente economica rispetto alla creazione e al mantenimento di connessioni TCP.
10.6. Uso della compressione
Quando comprime dati riservati nello stesso contesto di dati controllati da un attaccante, la compressione può permettere all'attaccante di recuperare i dati riservati. HTTP/3 abilita la compressione dei campi (Sezione 4.2).
Le implementazioni che comunicano su canali sicuri NON DEVONO comprimere contenuto che includa dati riservati e dati controllati dall'attaccante, a meno che non sia usato un contesto di compressione separato per ogni origine dei dati.
10.7. Padding e analisi del traffico
Il padding può essere usato per offuscare l'esatta dimensione del contenuto dei frame e per mitigare specifici attacchi a HTTP.
10.8. Analisi dei frame
Diversi elementi del protocollo contengono elementi di lunghezza annidati. Le implementazioni DEVONO assicurare che la lunghezza di un frame corrisponda esattamente alla lunghezza dei campi che contiene.
10.9. Dati anticipati
L'uso di 0-RTT con HTTP/3 comporta il rischio di attacchi di replay. Le mitigazioni anti-replay in [HTTP-REPLAY] DEVONO essere applicate quando HTTP/3 viene usato con 0-RTT.
10.10. Migrazione
Alcune implementazioni HTTP usano l'indirizzo del client per la registrazione o il controllo degli accessi. Poiché l'indirizzo di un client QUIC può cambiare durante la connessione, tali implementazioni devono recuperare attivamente l'indirizzo corrente del client o accettare esplicitamente che l'indirizzo originale possa cambiare.
10.11. Considerazioni sulla riservatezza
Diverse caratteristiche di HTTP/3 offrono agli osservatori l'opportunità di correlare nel tempo le operazioni di singoli client o server. Tra queste figurano i valori delle impostazioni, i tempi di reazione agli stimoli e l'elaborazione di qualsiasi funzionalità controllata dalle impostazioni.
La preferenza di HTTP/3 per l'uso di una singola connessione QUIC permette di correlare le attività di un utente su un sito.