7. Considerazioni sulla sicurezza (Security Considerations)

Questa sezione descrive le aree potenziali di preoccupazione per la sicurezza con HPACK:

• Uso della compressione come oracolo basato sulla lunghezza per verificare ipotesi su segreti che sono compressi in un contesto di compressione condiviso.

• Denial of service risultante dall'esaurimento della capacità di elaborazione o memoria di un decodificatore.

7.1. Sondaggio dello stato della tabella dinamica (Probing Dynamic Table State)

HPACK riduce la lunghezza delle codifiche dei campi di intestazione sfruttando la ridondanza inerente a protocolli come HTTP. L'obiettivo finale di ciò è ridurre la quantità di dati necessari per inviare richieste o risposte HTTP.

Il contesto di compressione utilizzato per codificare i campi di intestazione può essere sondato da un attaccante che può sia definire campi di intestazione da codificare e trasmettere sia osservare la lunghezza di questi campi una volta che sono codificati. Quando un attaccante può fare entrambe le cose, può modificare in modo adattivo le richieste per confermare ipotesi sullo stato della tabella dinamica. Se un'ipotesi viene compressa in una lunghezza più breve, l'attaccante può osservare la lunghezza codificata e dedurre che l'ipotesi era corretta.

Questo è possibile anche sul protocollo TLS (Transport Layer Security) (vedere [TLS12]), poiché sebbene TLS fornisca protezione della riservatezza per il contenuto, fornisce solo una quantità limitata di protezione per la lunghezza di quel contenuto.

Nota: Gli schemi di padding forniscono solo una protezione limitata contro un attaccante con queste capacità, richiedendo potenzialmente solo un numero maggiore di ipotesi per apprendere la lunghezza associata a una determinata ipotesi. Gli schemi di padding funzionano anche direttamente contro la compressione aumentando il numero di bit trasmessi.

Attacchi come CRIME [CRIME] hanno dimostrato l'esistenza di queste capacità generali dell'attaccante. L'attacco specifico ha sfruttato il fatto che DEFLATE [DEFLATE] rimuove la ridondanza basata sulla corrispondenza di prefissi. Ciò ha consentito all'attaccante di confermare le ipotesi un carattere alla volta, riducendo un attacco a tempo esponenziale a un attacco a tempo lineare.

7.1.1. Applicabilità a HPACK e HTTP (Applicability to HPACK and HTTP)

HPACK mitiga ma non previene completamente gli attacchi modellati su CRIME [CRIME] forzando un'ipotesi a corrispondere a un intero valore del campo di intestazione piuttosto che a caratteri individuali. Gli attaccanti possono solo apprendere se un'ipotesi è corretta o meno, quindi sono ridotti a ipotesi a forza bruta per i valori dei campi di intestazione.

La fattibilità del recupero di valori specifici dei campi di intestazione dipende quindi dall'entropia dei valori. Di conseguenza, i valori con alta entropia è improbabile che vengano recuperati con successo. Tuttavia, i valori con bassa entropia rimangono vulnerabili.

Attacchi di questa natura sono possibili ogni volta che due entità reciprocamente diffidenti controllano richieste o risposte che sono poste su una singola connessione HTTP/2. Se il compressore HPACK condiviso consente a un'entità di aggiungere voci alla tabella dinamica e all'altra di accedere a tali voci, allora lo stato della tabella può essere appreso.

Avere richieste o risposte da entità reciprocamente diffidenti si verifica quando un intermediario:

• invia richieste da più client su una singola connessione a un server di origine, o

• prende risposte da più server di origine e le pone su una connessione condivisa a un client.

I browser Web devono anche presumere che le richieste effettuate sulla stessa connessione da diverse origini Web (vedere [ORIGIN]) siano effettuate da entità reciprocamente diffidenti.

7.1.2. Mitigazione (Mitigation)

Gli utenti di HPACK possono adottare misure per limitare il potenziale di sondaggio della tabella dinamica limitando la capacità delle entità reciprocamente diffidenti di aggiungere voci alla tabella dinamica e di osservare lo stato della tabella dinamica.

La mitigazione più efficace consiste nell'evitare di condividere connessioni o contesti di compressione tra richieste o risposte che non sono il risultato di azioni della stessa origine.

Per gli intermediari, ciò significa che le richieste da client diversi e le risposte da server di origine diversi NON DEVONO (MUST NOT) condividere un singolo contesto di compressione HPACK.

Per gli agenti utente, ciò significa che i contesti di compressione DEVONO (MUST) essere separati per le richieste a origini diverse che non sono note per essere sotto controllo comune.

7.1.3. Letterali mai indicizzati (Never-Indexed Literals)

Le implementazioni possono anche scegliere di proteggere i campi di intestazione sensibili non comprimendoli e invece codificando il loro valore come letterali.

Rifiutare di generare una rappresentazione indicizzata per un campo di intestazione è efficace solo se la compressione viene evitata su tutti gli hop. Il bit letterale mai indicizzato (vedere sezione 6.2.3) può essere utilizzato per segnalare agli intermediari che un particolare valore è stato intenzionalmente inviato come letterale.

Un intermediario NON DEVE (MUST NOT) ricodificare un campo di intestazione che utilizza la rappresentazione letterale mai indicizzato con un'altra rappresentazione che lo indicizzerebbe. Se HPACK viene utilizzato per la ricodifica, può essere utilizzata invece una rappresentazione letterale senza indicizzazione (vedere sezione 6.2.2).

La scelta di utilizzare una rappresentazione letterale mai indicizzato per un campo di intestazione dipende da diversi fattori. Poiché HPACK non protegge dall'indovinare un intero valore del campo di intestazione, i valori brevi o a bassa entropia sono più facilmente recuperati da un avversario. Pertanto, un codificatore potrebbe scegliere di non indicizzare valori a bassa entropia.

Un codificatore potrebbe anche scegliere di non indicizzare i valori per i campi di intestazione considerati altamente preziosi o sensibili al recupero, come i campi di intestazione Cookie o Authorization.

7.2. Codifica Huffman statica (Static Huffman Encoding)

Non è attualmente noto alcun attacco contro una codifica Huffman statica. Uno studio ha mostrato che l'uso di una tabella di codifica Huffman statica ha creato una perdita di informazioni; tuttavia, quello stesso studio ha concluso che un attaccante non potrebbe sfruttare questa perdita di informazioni per recuperare una quantità significativa di informazioni (vedere [PETAL]).

7.3. Consumo di memoria (Memory Consumption)

Un attaccante può tentare di fare in modo che un endpoint esaurisca la sua memoria. HPACK è progettato per limitare le quantità di memoria allocate da un endpoint, sia al picco che in modo stabile.

La quantità di memoria utilizzata dal contesto di compressione può essere limitata impostando una dimensione massima per la tabella dinamica. In HTTP/2, questo è controllato dal parametro SETTINGS_HEADER_TABLE_SIZE (vedere sezione 6.5.2 di [HTTP2]).

Un codificatore può limitare la quantità di stato che può essere creato presso un decodificatore controllando la dimensione della tabella dinamica. In HTTP/2, questo è riportato dal decodificatore tramite l'uso del parametro SETTINGS_HEADER_TABLE_SIZE. Un codificatore DEVE (MUST) limitare la dimensione della tabella dinamica al valore riportato dal decodificatore, controllando così la quantità di memoria impegnata.

Un decodificatore può limitare la quantità di memoria impegnata nella tabella dinamica segnalando un valore SETTINGS_HEADER_TABLE_SIZE inferiore al valore predefinito. In HTTP/2, il valore predefinito è 4.096 ottetti, il che significa che il codificatore può utilizzare fino a questa quantità di memoria per la tabella dinamica a meno che il decodificatore non modifichi questo valore inviando un parametro SETTINGS_HEADER_TABLE_SIZE in un frame SETTINGS.

7.4. Limiti di implementazione (Implementation Limits)

Un'implementazione deve definire un limite per i valori che accetta per gli interi e per la dimensione dei letterali di stringa. Allo stesso modo, deve definire un limite al numero di voci che memorizzerà nella tabella dinamica. Non definire un limite potrebbe esporre un'implementazione ad attacchi, simili a quanto osservato nelle implementazioni di protocollo che non hanno definito limiti ragionevoli.

---