Mein Apache ist 2.4.46 und verwendet Openssl Version 1.1.1f
Ich habe die Direktive gesetzt SSLCompression Off. Selbst wenn ich sie aktiviere, heißt es, dass SSL-Komprimierung nicht unterstützt wird, was wohl gut ist.
Wenn ich jedoch Firefox verwende, um die HTTP-Header der Webseite anzuzeigen, werden mir diese Antwort-Header angezeigt:
HTTP/2 200 OK
date: Fri, 25 Dec 2020 12:13:58 GMT
server: Apache
expires: -1
cache-control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
content-security-policy: default-src https: 'unsafe-inline' 'unsafe-hashes' 'self'; img-src data: https: 'self'
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: no-referrer
permissions-policy: geolocation=();midi=();notifications=();push=();sync-xhr=(self);microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();
vary: Accept-Encoding
content-encoding: gzip
content-length: 3299
content-type: text/html; charset=UTF-8
X-Firefox-Spdy: h2
Das Ding, das sagt: content-encoding: gzipmacht mir Sorgen.
Aber auch wenn ich cURL verwende, um die Seite mit diesem Skript in PHP abzurufen:
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
//enable headers
curl_setopt($ch, CURLOPT_HEADER, 1);
//get only headers
curl_setopt($ch, CURLOPT_NOBODY, 1);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 5000);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2_0);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0");
curl_setopt($ch, CURLOPT_ENCODING, "gzip");
Es gibt diese HTTP-Header zurück:
HTTP/2 200
date: Fri, 25 Dec 2020 12:16:45 GMT
server: Apache
set-cookie: __Secure-CCJRLSESSID=g7m99kljvea2g5uk58f5lfskr1; path=/; secure; HttpOnly; SameSite=Lax
expires: -1
cache-control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
content-security-policy: default-src https: 'unsafe-inline' 'unsafe-hashes' 'self'; img-src data: https: 'self'
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: no-referrer
permissions-policy: geolocation=();midi=();notifications=();push=();sync-xhr=(self);microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();
content-type: text/html; charset=UTF-8
Das verwirrt mich. Ich habe sogar den Cache in Firefox geleert, aber ohne Erfolg. Ich möchte nicht anfällig für den CRIME-Angriff sein. Stattdessen könnte ich gzip einfach vollständig deaktivieren. Aber bevor ich das tue, möchte ich wissen, warum das passiert. Vielleicht ein Fehler in Firefox??
Aktualisieren:
Es passiert auch in Chrom.
mod_deflate-Konfiguration:
SSLCompression Off
<IfModule deflate_module>
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
</IfModule>
Antwort1
Um deine Frage zu beantworten, ist es hilfreich, ein wenig über die Hintergründe zu wissen:
Hintergrund – warum stellt die Verwendung von Komprimierung möglicherweise ein Sicherheitsrisiko dar?
Es gibt einige sogenannte „Compression Side Channel Attacks“, die im Grunde genommen die Ergebnisse der Komprimierung nutzen, um den Originaltext zu erraten. Jeder dieser Angriffe funktioniert im Grunde so, dass man der Eingabe zur Komprimierung etwas hinzufügen und dann die Ausgabe beobachten kann. Dies liegt daran, dass viele Komprimierungsalgorithmen funktionieren, indem sie wiederholten Text erkennen und durch Referenzen ersetzen, anstatt den Text mehrmals vollständig zu wiederholen. Dies führt zu kleineren Nachrichten, eröffnet aber eine Angriffsmöglichkeit.
Wie funktionieren diese Angriffe?
Grundsätzlich gilt: Wenn Sie den geheimen Teil ganz oder teilweise erraten, fügen Sie ihn zusammen mit dem unbekannten geheimen Teil der Nachricht hinzu und beobachten Sie dann die Größe des verschlüsselten Ergebnisses. Wenn es bei bestimmten Vermutungen kleiner wird, müssen Sie einen Teil der Nachricht wiederholt haben und somit von der höheren Komprimierung profitiert haben.
Mit ein paar Vermutungen ist es möglich, den geheimen Teil herauszufinden. Dies hängt davon ab, ob Sie der Nachricht etwas hinzufügen können, aber es gibt verschiedene Methoden, dies zu tun. Wenn Sie beispielsweise wissen möchten, ob ein tokenCookie für example.com gesetzt ist, senden Sie eine Nachricht (vielleicht eine versteckte XHR-Nachricht, die angezeigt wird, wenn Personen Ihre völlig unabhängige Site besuchen?) an example.com?token=1und messen Sie die resultierende Nachrichtengröße (da der Browser das Cookie automatisch ebenfalls zur Nachricht hinzufügt). Versuchen Sie dann example.com?token=2herauszufinden, ob es größer, kleiner oder gleich ist. Wiederholen Sie dies für alle möglichen Werte, bis Sie das erste Zeichen des Cookies herausgefunden haben, bei dem die Nachricht kleiner wird. Nehmen wir in diesem Beispiel an, es ist token=5. Versuchen Sie es dann mit dem zweiten Zeichen (z. B. example.com?token=51, example.com?token=52... usw.). Wiederholen Sie dies, bis Sie das vollständige Cookie haben.
Sie können die Länge der Nachricht entweder direkt messen (z. B. indem Sie die verschlüsselten Nachrichten beobachten, wenn SieDer Mann in der Mittedas Netzwerk) oder messen Sie, wie lange das Senden der Nachricht dauert, um die Länge gut schätzen zu können.
HTTP-Nachrichten können auf verschiedene Arten komprimiert werden
Die Komprimierung kann in einer HTTP-Nachricht auf verschiedenen Ebenen erfolgen: 1) auf der SSL/TLS-Ebene, 2) auf der HTTP-Body-Ebene und 3) auf der HTTP-Header-Ebene.
SSL-Komprimierung
Die SSL/TLS-Komprimierung erfolgt grundsätzlich unabhängig davon, ob es sich um eine HTTP-Nachricht handelt - sie wird auf SSL/TLS-Ebene durchgeführt. Angriffe wieVERBRECHENhat uns im Grunde davon abgehalten, SSL/TLS-Komprimierung zu verwenden, da es zu viele Möglichkeiten einführte, versteckte Teile der Nachricht zu erraten, im Grunde genommen mit dem obigen Algorithmus. Ehrlich gesagt waren die Vorteile der SSL/TLS-Komprimierung ohnehin nicht so groß, insbesondere wenn wir die Body-Antwort bereits auf der zugrunde liegenden HTTP-Ebene mit gzip oder ähnlichem komprimiert haben, sodass eine erneute Komprimierung nach der Verschlüsselung nicht wirklich viel mehr Daten sparte. Es gab also keinen wirklichen Grund, sie zu verwenden, und dies gab einen echten GrundNICHTum es zu verwenden. SSL/TLS-Komprimierung sollte immer ausgeschaltet sein und ein Tool wieSSLLabsum dies zu bestätigen. Auf den meisten Servern ist es standardmäßig deaktiviert und das schon seit einiger Zeit, daher wäre ich sehr überrascht, wenn es aktiviert wäre.
HTTP-Body-Komprimierung
Interessanter ist die Komprimierung auf HTTP-Body-Ebene. Dabei wird typischerweise gzip oder der neuere Brotli-Algorithmus verwendet undISTIn den meisten Fällen wird empfohlen, diese Option zu aktivieren, da die Webleistung erheblich verbessert wird. Dies liegt daran, dass HTTP-Bodies häufig groß sind (besondere Antwort-Bodies) und Netzwerke normalerweise relativ langsam sind. Daher sind kleinere Größen im Netzwerk wirklich vorteilhaft. Nun, theoretisch ist dies anfällig für ähnliche Angriffe (die so genanntenBREACH-Angriffund auch dieZEITVariante) – aber nur, wenn die geheimen Daten wieder im Textkörper enthalten sind (so dass jede identische Vermutung nach der Komprimierung kleiner erscheinen kann). Das Risiko ist also viel geringer, da die meisten Antworten keine geheimen Daten enthalten (z. B. wann haben Sie Ihr Cookie das letzte Mal auf einer Seite auf dem Bildschirm gedruckt gesehen?), während Cookies in Kopfzeilen oft immer enthalten sind und einen größeren Teil der Nachricht ausmachen.
Wenn Sie natürlich geheime Informationen haben, die auf dem Bildschirm gedruckt werden (Ihr Name, Sozialversicherungsnummer, Geburtsdatum, Bankdaten usw.), könnte dies gefährdet sein und Sie sollten vielleicht in Betracht ziehen, diese Antworten nicht per HTTP zu komprimieren, aber diese sind ziemlich untypisch, also deaktivieren Sie die HTTP-Komprimierung fürjedenAntwort ist selten die richtige Antwort. Selbst wenn Sie geheime Informationen auf dem Bildschirm präsentieren, gibt es bessere Optionen: Beispielsweise diese Daten überhaupt nicht oder zumindest nicht vollständig auf dem Bildschirm anzuzeigen (z. B. alle bis auf die letzten 4 Ziffern mit Sternchen zu versehen), die gleichzeitige Anzeige von Benutzerantwortdaten auf dem Bildschirm zu verhindern, die Daten mit zufälligen Zeichen aufzufüllen oder eine Ratenbegrenzung hinzuzufügen, sind normalerweise viel bessere Optionen.
Zurück zu Ihrer Frage
Um Ihre Frage zu beantworten: SSL-Komprimierung und HTTP-Body-Komprimierung sind zwei verschiedene Dinge, und erstere sollteausund letzteresAn(außer bei wirklich sicheren Anwendungen, die dies trotz der Vorteile nicht riskieren möchten – aber selbst dann gibt es normalerweise bessere Möglichkeiten, damit umzugehen).
Zum Abschluss noch ein paar Bonusinfos zur HTTP-Header-Komprimierung
Lassen Sie uns zum Abschluss der Geschichte über die Komprimierung von HTTP-Headern sprechen, da diese, wie oben erwähnt, häufig Cookie-Geheimnisse enthalten, die für Angreifer wertvoll sein könnten.
HTTP/1.1, bis vor kurzem die vorherrschende Version, erlaubte dies nicht, daher gab es hier nicht viel zu sagen. Diese wurden vollständig unkomprimiert gesendet (wenn auch verschlüsselt mit SSL/TLS, wenn HTTPS verwendet wurde) und waren daher nicht anfällig für Side-Channel-Komprimierungsrisiken (vorausgesetzt, es wurde keine SSL-Komprimierung verwendet).
Diese waren im Vergleich zu HTTP-Bodys normalerweise auch sehr klein, sodass sich niemand wirklich Gedanken darüber machte, sie zu stark zu komprimieren. Mit der zunehmenden Anzahl von Ressourcen, die zum Erstellen einer Webseite verwendet werden (über 100 sind heutzutage nicht ungewöhnlich), gibt es jedoch eine Menge Redundanz, wenn ständig praktisch dieselben HTTP-Header hin und her gesendet werden (haben Sie beispielsweise die Größe des User-Agent-Headers gesehen, der mit jeder einzelnen Anfrage gesendet wird, sich aber bei all diesen Anfragen nie ändert?).
Die neueren Protokolle HTTP/2 und HTTP/3, die bald veröffentlicht werden, erlauben zwar die Komprimierung von HTTP-Headern, wählen aber ausdrücklich einen Komprimierungsalgorithmus (HPACK für HTTP/2 und das ähnliche QPACK für HTTP/3), der für diese Angriffe nicht anfällig ist. Dies war übrigens eine explizite Entscheidung, da das frühere SPDY-Protokoll, auf dem HTTP/2 basierte, gzip verwendete und daher anfällig war. Als dies bekannt wurde, musste es im Rahmen der Standardisierung auf HTTP/2 geändert werden.
Warum nicht immer die „sichere Komprimierung“ verwenden?
Warum können wir also nicht auch sichere Komprimierungstechniken (wie HPACK oder QPACK) für HTTP-Antworttexte verwenden und dies vermeiden? Nun, es handelt sich dabei um sehr spezifische Komprimierungstechniken, die Wörterbücher oder bekannte und wiederholte Werte verwenden. Dies funktioniert gut für HTTP-Header, bei denen es nur wenige Werte gibt und diese häufig wiederholt werden, ist aber keine wirkliche Option für allgemeinere HTTP-Textantworten, bei denen jede Antwort wahrscheinlich völlig anders ist.
Hoffe, das erklärt einige Dinge und beantwortet somit Ihre Frage.
Antwort2
Der CRIME-Angriff gegenCVE-2012-4929geht es darum, die komprimierten Header zu verschlüsseln, ohne die Länge der unverschlüsselten Daten zu verschleiern, wodurch es möglich wird, Klartext-Header (durch Erraten) offenzulegen.
In Ihrem Fall wird der Inhalt komprimiert, die Größe (Länge) der komprimierten Daten wird als weiterer Header hinzugefügt und dann wird das Ganze verschlüsselt. Dies ist nicht anfällig für den CRIME-Angriff, da die Länge unverschlüsselter Daten nie preisgegeben wird.