Es wird ein Request (durch den Angreifer) im Kontext einer bestehenden Benutzer-Session gesendet. Der Request enthält eine geratene Zeichenkette, von der vermutet wird, dass sie in den Daten auf der Seite vorkommt. Dabei wird der die Zeichenfolge als Eingabe zum Beispiel in ein Suchfeld eingegeben. Außerdem wird dem Server mitgeteilt das der Client gzip-Komprimierung unterstützt.
Der Response wird die gesendete Zeichenkette wieder enthalten(zum Beispiel weil sie in einem Suchfeld als Teil der Suche war un din den Suchergebnissen wieder auftaucht).
Der Angreifer kann zwar den Response nicht lesen, weil er verschlüsselt ist, aber wenn er an einer entsprechenden Stelle im Netzwerk sitzt kann er den verschlüsselten Response empfangen.
Wenn er mit mehreren Zeichenketten gleicher Länge zuvor getestet hat, kann er sagen wie groß das Antwort-Paket sein wird, wenn die Zeichenkette auf der Ergebnisseite nur einmal vorkommt (einmal → die geratene Zeichenkette ist nur Teil der Antwort weil sie im Suchfeld steht/eine entsprechende Fehlerseite angezeigt wird die den String enthält) oder mehrfach vorkommt (das Paket wird kleiner, weil Kompression erhöht).
Der Angreifer kann viele Requests senden und dadurch mehr und mehr Daten erraten.

• Angreifer sendet Request
  • Request enthält eine Zeichenkette als Teil eines Formulars, welches im Response auch wieder erscheint
  • der Request signalisiert das der Client gzip-Komprimierung kann
• Server antwortet mit dem verschlüsselten Response
  • der Response ist gzip komprimiert
  • die Im Request gesendete Zeichenkette ist im Response erhalten
• Angreifer hat keinen Zugriff auf den entschlüsselten Response
  • Angreifer kann aber den Response (verschlüsselt) im Netzwerk mitelesen
  • Angreifer kann anhand der Länge des Responses sagen ob die gesendete Zeichenkette im Response mehrfach vorkommt
    • die verwendete gzip-Komprimierung ist um so effektiver um so öfter eine Zeichenkette vorkommt → das Paket wird kleiner
• Angreifer kann immer neue Requests mit neuen Zeichenketten senden und dadurch immer größere Teile des verschlüsselten Dokuments sichtbar machen

• Angreifer muss Requests im Kontext einer aktiven Benutzer-Sitzung senden können
  • es werden weitere Angriffe benötigt um das zu schaffen
  • per Cross-Site-Scripting
• der Server muss gzip-Komprimierung beherrschen (können die meisten per Default)
• Daten aus dem Request müssen im Response wieder auftauchen
  • zum Beispiel durch ein Formular moder Suchfeld
• der Angreifer muss Netzwerkverkehr zwischen Server und Client mitschneiden können

Grundsätzlich alle die auf einer Website sind, der Angreifer muss nur lang genug raten können.

Es können aber vor allem auch Security-Tokens erraten werden, wenn sich diese im Body des Responses befinden (folglich also auch komprimiert werden und somit erkannt werden können wie Website-Inhalte).
Errät ein Angreifer das Token kann er gegebenfalls die Session übernehmen und braucht den Rest der Seite nicht mehr zu erraten.

• Header sind davon ausgeschlossen
  • steht also das Security-Token im Header kann es nicht auf dem Weg erraten werden

Es gibt einen ähnlichen Angriff der die (selten aktive) Komprimierung im SSL-Protokoll selbst als Angrifsvektor benutzt. Funktioniert im Prinzip gleich, nur ist da nicht im http die Komprimierung aktiviert, sondern auf TLS/SSL-Ebene.