Kompresja GZIP na problemie bezpieczeństwa ruchu HTTPS z attacheiem BREACH/CRIME?

Question

Na przykład, gdy przyjrzeć nagłówek HTTP https://www.facebook.com widzę, że korzystają one z kompresji GZIP Content-Encoding: gzip z ruchu SSL/TLS.

Czy to nie jest zły pomysł z powodu ataku TRZECI/ZBRODNI?

curl -I -H 'Accept-Encoding: gzip,deflate' https://www.facebook.com 
HTTP/1.1 200 OK 
Pragma: no-cache 
Cache-Control: private, no-cache, no-store, must-revalidate 
Expires: Sat, 01 Jan 2000 00:00:00 GMT 
Strict-Transport-Security: max-age=15552000; preload 
Vary: Accept-Encoding 
Content-Encoding: gzip 
Content-Type: text/html 
Date: Fri, 15 May 2015 18:56:11 GMT 
Connection: keep-alive 
Content-Length: 15101 

Według http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29

Answer 1

ZŁAMANIE istnieje, gdy masz TLS plus kompresję HTTP (tj gzip). Ale wymaga również:

1. przydatna, tajne informacje w organizmie reakcji
2. atakująca musi być w stanie wprowadzić wartość w organizmie reakcji z parametrem żądania
3. bez dopełnienia losowo odpowiedź

Komentarze:

1. Hakerzy są po numerów kart kredytowych, haseł, tokenów CSRF i prawdopodobnie nie rozmawia z GF, ale nigdy nie wiadomo.

2. Wygląda na to, że wiele odpowiedzi wejściowych (np. Pasek wyszukiwania) jest poza pasmem, tj. Odpowiedź jest nad AJAX, więc nie ma wpływu na inne odpowiedzi.

3. Facebook może wypełniać swoje odpowiedzi, ale nie zagłębiłem się zbytnio w to.