Compressione brotli per HTTPS

Question

Compressione brotli per HTTPS

#1 da (7 voti)

8

Sembra che Chrome, Firefox e presto Edge, supportino il nuovo algoritmo di compressione Brotli solo su HTTPS.

Non riesco a trovare nulla sul fatto che questo nuovo algoritmo di compressione sia suscettibile all'attacco BREACH. L'unica cosa rilevante che ho trovato era alla fine della sezione 12 di RFC 7932 :

A possible attack against a system that sends compressed data over an encrypted channel is the following. An attacker who can repeatedly mix arbitrary (attacker-supplied) data with secret data (passwords, cookies) and observe the length of the ciphertext can potentially reconstruct the secret data. To protect against this kind of attack, applications should not mix sensitive data with non-sensitive, potentially attacker-supplied data in the same compressed stream.

Da quel paragrafo sembra che Brotli sia ancora suscettibile di VIOLAZIONE. Se la mia comprensione di BREACH (e del relativo attacco CRIME) è corretta, la compressione non è sicura su HTTPS.

In questo caso è sicuro usare Brotli per i contenuti HTTPS? In caso contrario, perché i produttori di browser lo supportano?

http compression tls

posta rink.attendant.6 04.02.2017 - 05:16

fonte

1 risposta

Leggi altre domande sui tag http compression tls

Protezione CSRF necessaria per i clienti che non accettano i cookie? Il browser Chrome segnala il cifrario obsoleto (AES_256_CBC con HMAC-SHA1)

score 7 · Accepted Answer

support the new Brotli compression algorithm over HTTPS only.

In teoria si. In pratica Chrome accetterà attualmente risposte brotli compresse anche con HTTP semplice, anche se non annuncia il supporto per brotli in HTTP semplice. Firefox supporta solo le risposte in HTTPS.

If my understanding of BREACH (and the related CRIME attack) is correct, compression is unsafe over HTTPS.

Questa è una generalizzazione sbagliata. L'attacco BREACH riguarda solo il contenuto dinamico che contiene informazioni segrete come i token CSRF che l'utente malintenzionato ama indovinare. Funziona solo se l'autore dell'attacco è in grado di riflettere i propri dati nel contenuto originale come nel caso di dati riflessi da moduli compilati. L'utente malintenzionato deve inoltre essere in grado di rilevare le modifiche nella dimensione del contenuto compresso, ovvero utilizzando lo sniffing passivo della connessione (classico attacco BREACH) o attraverso il timing ( attacco HEIST ). È ancora sicuro comprimere il contenuto in cui non è possibile alcuna riflessione e, naturalmente, il contenuto che non contiene segreti che l'aggressore ama indovinare. Ciò significa in particolare che la compressione del contenuto statico è sicura.
Per quanto riguarda l'attacco CRIME è sufficiente disabilitare la compressione di livello TLS che i browser correnti hanno già fatto. CRIME non ha nulla a che fare con la compressione del contenuto in HTTPS.
Vedi anche È possibile eseguire il gopping del contenuto tramite TLS .