Se la compressione TLS non è supportata, un sito è ancora vulnerabile ad attacchi come BREAK?

Dalla BREAK pagina di Wikipedia:

BREACH exploits the compression in the underlying HTTP protocol. Therefore, turning off TLS compression makes no difference to BREACH, which can still perform a chosen-plaintext attack against the HTTP payload.

Tuttavia, CRIME può essere mitigato rimuovendo il supporto per la compressione TLS.

In TLS l'algoritmo di compressione è negoziato tra il client e il server. Il client propone un elenco di algoritmi adatti e il server ne sceglie uno da quel set. Devono concordare un algoritmo e, in caso contrario, la connessione fallisce. Quindi per CRIME richiede il supporto della compressione da entrambe le estremità.

Tuttavia, come indicato sopra per BREACH, la compressione HTTP viene sfruttata, non la compressione TLS. Compressione HTTP :

HTTP data is compressed before it is sent from the server: compliant browsers will announce what methods are supported to the server before downloading the correct format; browsers that do not support compliant compression method will download uncompressed data.

Sulla base di questo, sia il client che il server dovrebbero supportare un tipo di compressione (generalmente GZIP o DEFLATE) per far funzionare questo attacco.

BREACH e CRIME non compromettono i siti, perché sono attacchi ai client , non sui server. Il server è ancora coinvolto in questo, ad esempio, la compressione TLS non verrà utilizzata a meno che il server non accetti; in modo che, anche se l'attacco CRIME abbia come target il client, il server può rifiutarsi di utilizzare la compressione e questo protegge indirettamente i client vulnerabili.

Entrambi gli attacchi si riferiscono allo stesso principio generale: la crittografia nasconde il contenuto dei dati, ma non la dimensione dei dati. La compressione rende le dimensioni dei dati dipendenti dal contenuto dei dati. Pertanto, la compressione può perdere informazioni sui contenuti dei dati che la crittografia non protegge. Se l'attaccante si trova in una posizione in cui può iniettare alcuni dati propri insieme ai dati che tenta di recuperare (formalmente, un selected-plaintext attack ), quindi vince.

CRIME era un'applicazione di questo concetto per la compressione a livello TLS in un contesto Web. Il Web consente Javascript, che può essere ostile ed emettere richieste (soggetto a qualche vincolo nel caso di richieste cross-site); questo è il modo in cui l'attaccante può raggiungere una situazione di CPA. La disattivazione della compressione a livello TLS risolve il problema e non era realmente risolvibile in alcun altro modo, perché la perdita di dati indotta dalla compressione è un concetto molto generico. Nota che la compressione a livello HTTP non fa nulla a favore o contro CRIME, poiché CRIME si concentra sull'intestazione (il percorso della richiesta e il cookie).

BREACH è un'altra applicazione del concetto, questa volta con compressione a livello HTTP. La compressione a livello HTTP viene eseguita solo sui corpi delle richieste, non sulle intestazioni HTTP, quindi BREACH è più difficile da estrarre (mentre il CRIME ha funzionato ogni volta che un cookie era coinvolto, BREACH richiede che il contenuto del sito sia suscettibile in qualche modo all'attacco). La disabilitazione della compressione TLS non comporterà nulla a favore o contro BREACH.

In ogni caso, la compressione (sia per TLS che per i corpi di richiesta / risposta HTTP) verrà applicata da qualsiasi macchina solo se è ragionevolmente sicuro che la macchina all'altra estremità della connessione lo capirà - a causa di alcuni indicazione precedente a tale effetto (nel messaggio ClientHello TLS per TLS, in un'intestazione di richiesta per HTTP). Non ci sarà compressione, quindi nessun attacco, a meno che sia il client che il server lo supportino e acconsentano a usarlo. In questo modo è possibile applicare attenuazioni per gli attacchi ai client sul server.