HTTP-Komprimierung - HTTP compression

HTTP
Anfragemethoden
Kopfzeilenfelder
Antwortstatuscodes
Methoden der Sicherheitszugriffssteuerung
Sicherheitslücken

HTTP-Komprimierung ist eine Funktion, die in Webserver und Webclients integriert werden kann , um die Übertragungsgeschwindigkeit und Bandbreitennutzung zu verbessern.

HTTP-Daten werden komprimiert, bevor sie vom Server gesendet werden: kompatible Browser geben dem Server bekannt, welche Methoden unterstützt werden, bevor sie das richtige Format herunterladen; Browser, die keine kompatible Komprimierungsmethode unterstützen, laden unkomprimierte Daten herunter. Zu den gängigsten Komprimierungsschemata gehören gzip und Brotli ; Die IANA führt jedoch eine vollständige Liste der verfügbaren Schemata .

Es gibt zwei verschiedene Möglichkeiten, die Komprimierung in HTTP durchzuführen. Auf einer niedrigeren Ebene kann ein Transfer-Encoding-Header-Feld anzeigen, dass die Nutzlast einer HTTP-Nachricht komprimiert ist. Auf einer höheren Ebene kann ein Content-Encoding-Header-Feld anzeigen, dass eine Ressource, die übertragen, zwischengespeichert oder anderweitig referenziert wird, komprimiert ist. Die Komprimierung mit Content-Encoding wird in größerem Umfang unterstützt als die Transfer-Encoding, und einige Browser bieten keine Unterstützung für die Transfer-Encoding-Komprimierung an, um das Auslösen von Fehlern in Servern zu vermeiden.

Aushandlung des Kompressionsschemas

Die Aushandlung erfolgt in zwei Schritten, die in RFC 2616 beschrieben sind:

1. Der Webclient gibt bekannt, welche Komprimierungsschemata er unterstützt, indem er eine Liste von Token in die HTTP-Anfrage einfügt . Bei Content-Encoding befindet sich die Liste in einem Feld namens Accept-Encoding ; für Transfer-Encoding heißt das Feld TE . 

GET /encrypted-area HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, deflate

2. Wenn der Server ein oder mehrere Komprimierungsschemata unterstützt, können die ausgehenden Daten durch ein oder mehrere Verfahren komprimiert werden, die von beiden Parteien unterstützt werden. Wenn dies der Fall ist, fügt der Server in der HTTP-Antwort ein Feld für Content-Encoding oder Transfer-Encoding mit den verwendeten Schemata, durch Kommas getrennt, hinzu. 

HTTP/1.1 200 OK
Date: mon, 26 June 2016 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip

Der Webserver ist in keiner Weise zu einer Kompressionsmethode verpflichtet – dies hängt von den internen Einstellungen des Webservers ab und kann auch von der internen Architektur der jeweiligen Website abhängen.

Inhaltscodierungstokenken

Die offizielle Liste der für Server und Clients verfügbaren Token wird von der IANA verwaltet und umfasst:

  • br – Brotli , ein Komprimierungsalgorithmus, der speziell für die HTTP-Inhaltscodierung entwickelt wurde, in RFC 7932 definiert und in allen modernen gängigen Browsern implementiert ist.
  • Komprimieren – UNIX-Programmmethode "compress" (historisch; in den meisten Anwendungen veraltet und durch gzip oder deflate ersetzt)
  • deflate – Komprimierung basierend auf dem Deflate- Algorithmus (beschrieben in RFC 1951), einer Kombination aus dem LZ77- Algorithmus und der Huffman-Codierung, verpackt in das zlib -Datenformat (RFC 1950);
  • exi – W3C Effizienter XML-Austausch
  • gzip – GNU-Zip-Format (beschrieben in RFC 1952). Verwendet den Deflate- Algorithmus für die Komprimierung, aber das Datenformat und der Prüfsummenalgorithmus unterscheiden sich von der Inhaltscodierung "deflate". Diese Methode ist die am weitesten verbreitete Methode (Stand März 2011).
  • Identität – Es wird keine Transformation verwendet. Dies ist der Standardwert für die Inhaltscodierung.
  • pack200-gzip – Netzwerkübertragungsformat für Java-Archive
  • zstd – Zstandard- Komprimierung, definiert in RFC 8478

Darüber hinaus wird eine Reihe inoffizieller oder nicht standardisierter Token von Servern oder Clients in freier Wildbahn verwendet:

  • bzip2 – Komprimierung basierend auf dem freien bzip2-Format, unterstützt von lighttpd
  • lzma – Komprimierung basierend auf (rohem) LZMA ist in Opera 20 und in elinks über eine Kompilierzeit-Option verfügbar
  • peerdist – Zwischenspeichern und Abrufen von Microsoft Peer-Inhalten
  • rsync - Delta-Codierung in HTTP , implementiert durch ein Paar von rproxy- Proxys.
  • xpress – Microsoft-Komprimierungsprotokoll, das von Windows 8 und höher für Windows Store-Anwendungsupdates verwendet wird. LZ77- basierte Komprimierung optional unter Verwendung einer Huffman-Kodierung.
  • xz - LZMA2-basierte Inhaltskomprimierung, unterstützt von einem nicht offiziellen Firefox-Patch; und seit 2013-12-31 vollständig im mget implementiert.

Server, die HTTP-Komprimierung unterstützen


Die Komprimierung in HTTP kann auch durch die Verwendung der Funktionalität von serverseitigen Skriptsprachen wie PHP oder Programmiersprachen wie Java erreicht werden .

Probleme, die die Verwendung der HTTP-Komprimierung verhindern

Ein Artikel der Google-Ingenieure Arvind Jain und Jason Glasgow aus dem Jahr 2009 besagt, dass täglich mehr als 99 Personenjahre verschwendet werden, da die Seitenladezeit verlängert wird, wenn Benutzer keine komprimierten Inhalte erhalten. Dies tritt auf, wenn Antivirensoftware Verbindungen stört, um deren Dekomprimierung zu erzwingen, wo Proxys verwendet werden (bei übervorsichtigen Webbrowsern), wenn Server falsch konfiguriert sind und wenn Browser-Bugs die Verwendung der Komprimierung verhindern. Internet Explorer 6, der hinter einem Proxy auf HTTP 1.0 (ohne Funktionen wie Komprimierung oder Pipelining) absinkt – eine gängige Konfiguration in Unternehmensumgebungen – war der Mainstream-Browser, der am anfälligsten für ein Failback auf unkomprimiertes HTTP war.

Ein weiteres Problem bei der Bereitstellung von HTTP-Komprimierung in großem Umfang ist auf die Definition der Deflate- Codierung zurückzuführen: Während HTTP 1.1 die Deflate- Codierung als mit Deflate (RFC 1951) komprimierte Daten in einem zlib- formatierten Stream (RFC 1950) definiert, sind Microsoft Server- und Client-Produkte in der Vergangenheit hat es als "rohen" deflationierten Strom implementiert, was seine Bereitstellung unzuverlässig macht. Aus diesem Grund implementieren einige Software, einschließlich des Apache HTTP Servers, nur die gzip- Codierung.

Auswirkungen auf die Sicherheit

Hauptartikel: CRIME und VERLETZUNG

Die Komprimierung ermöglicht die Durchführung einer bestimmten Form eines Klartextangriffs : Wenn ein Angreifer einen beliebigen ausgewählten Inhalt in die Seite einschleusen kann, kann er anhand der Größenzunahme des verschlüsselten Streams feststellen, ob die Seite den angegebenen Inhalt enthält. Ist der Anstieg geringer als bei zufälligen Injektionen erwartet, bedeutet dies, dass der Kompressor eine Wiederholung im Text gefunden hat, dh der injizierte Inhalt überlappt die geheimen Informationen. Das ist die Idee hinter CRIME.

Im Jahr 2012 wurde ein allgemeiner Angriff gegen den Einsatz von Datenkomprimierung mit dem Namen CRIME angekündigt. Während der CRIME-Angriff effektiv gegen eine Vielzahl von Protokollen funktionieren könnte, einschließlich, aber nicht beschränkt auf TLS, und Protokolle der Anwendungsschicht wie SPDY oder HTTP, wurden nur Exploits gegen TLS und SPDY demonstriert und in Browsern und Servern weitgehend entschärft. Der CRIME-Exploit gegen die HTTP-Komprimierung wurde überhaupt nicht gemildert, obwohl die Autoren von CRIME gewarnt haben, dass diese Schwachstelle möglicherweise noch weiter verbreitet ist als die Kombination von SPDY und TLS-Komprimierung.

Im Jahr 2013 wurde eine neue Instanz des CRIME-Angriffs gegen die HTTP-Komprimierung namens BREACH veröffentlicht. Ein BREACH-Angriff kann in nur 30 Sekunden (je nach Anzahl der zu extrahierenden Bytes) Login-Token, E-Mail-Adressen oder andere sensible Informationen aus TLS-verschlüsseltem Webverkehr extrahieren, vorausgesetzt, der Angreifer verleitet das Opfer dazu, einen schädlichen Weblink zu besuchen. Alle Versionen von TLS und SSL sind unabhängig vom verwendeten Verschlüsselungsalgorithmus oder der verwendeten Verschlüsselung durch BREACH gefährdet. Im Gegensatz zu früheren Instanzen von CRIME , die erfolgreich durch Deaktivieren der TLS-Komprimierung oder SPDY-Header-Komprimierung abgewehrt werden können, nutzt BREACH die HTTP-Komprimierung aus, die realistischerweise nicht deaktiviert werden kann, da praktisch alle Webserver darauf angewiesen sind, um die Datenübertragungsgeschwindigkeiten für Benutzer zu verbessern.

Ab 2016 sind der TIME-Angriff und der HEIST-Angriff nun öffentlich bekannt.

Verweise

Externe Links