Kompresja HTTP - HTTP compression

HTTP
Poproś o metody
Pola nagłówka
Kody statusu odpowiedzi
Metody kontroli dostępu do zabezpieczeń
Luki w zabezpieczeniach

Kompresja HTTP to funkcja, którą można wbudować w serwery WWW i klienty WWW, aby poprawić szybkość transferu i wykorzystanie przepustowości.

Dane HTTP są kompresowane przed wysłaniem z serwera: zgodne przeglądarki informują o tym, jakie metody są obsługiwane przez serwer przed pobraniem prawidłowego formatu; przeglądarki, które nie obsługują zgodnej metody kompresji, będą pobierać nieskompresowane dane. Najpopularniejszymi schematami kompresji są gzip i Brotli ; jednak pełna lista dostępnych programów jest prowadzona przez IANA .

Istnieją dwa różne sposoby kompresji w HTTP. Na niższym poziomie pole nagłówka Transfer-Encoding może wskazywać, że ładunek wiadomości HTTP jest skompresowany. Na wyższym poziomie pole nagłówka Content-Encoding może wskazywać, że przesyłany zasób, buforowany lub w inny sposób przywoływany, jest skompresowany. Kompresja przy użyciu kodowania zawartości jest szerzej obsługiwana niż kodowanie transferowe, a niektóre przeglądarki nie reklamują obsługi kompresji kodowania transferowego, aby uniknąć wywoływania błędów na serwerach.

Negocjacja schematu kompresji

Negocjacja odbywa się w dwóch krokach, opisanych w RFC 2616:

1. Klient sieciowy ogłasza, które schematy kompresji obsługuje, dołączając listę tokenów w żądaniu HTTP . W przypadku Content-Encoding lista znajduje się w polu o nazwie Accept-Encoding ; dla Transfer-Encoding , pole nazywa się TE . 

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

2. Jeśli serwer obsługuje jeden lub więcej schematów kompresji, dane wychodzące mogą być skompresowane przy użyciu jednej lub kilku metod obsługiwanych przez obie strony. W takim przypadku serwer doda w odpowiedzi HTTP pole Content-Encoding lub Transfer-Encoding z użytymi schematami oddzielonymi przecinkami. 

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

Serwer WWW nie jest w żaden sposób zobowiązany do stosowania jakiejkolwiek metody kompresji – zależy to od wewnętrznych ustawień serwera WWW, a także może zależeć od wewnętrznej architektury danego serwisu.

Tokeny do kodowania treści

Oficjalna lista tokenów dostępnych dla serwerów i klientów jest utrzymywana przez IANA i zawiera:

  • br – Brotli , algorytm kompresji zaprojektowany specjalnie do kodowania treści HTTP, zdefiniowany w RFC 7932 i zaimplementowany we wszystkich nowoczesnych głównych przeglądarkach.
  • compress – metoda programu UNIX "compress" (historyczna; przestarzała w większości aplikacji i zastąpiona przez gzip lub deflate)
  • deflate – kompresja oparta na algorytmie deflate (opisanym w RFC 1951), będącym kombinacją algorytmu LZ77 i kodowania Huffmana, opakowana w format danych zlib (RFC 1950);
  • exi – Wydajna wymiana XML W3C
  • gzip – format zip GNU (opisany w RFC 1952). Używa algorytmu deflate do kompresji, ale format danych i algorytm sumy kontrolnej różnią się od kodowania treści „deflate”. Ta metoda jest najszerzej obsługiwana od marca 2011 r.
  • tożsamość — nie jest używana żadna transformacja. Jest to domyślna wartość kodowania treści.
  • pack200-gzip – format przesyłania sieciowego dla archiwów Java
  • zstd – kompresja Zstandard , zdefiniowana w RFC 8478

Oprócz tego wiele nieoficjalnych lub niestandardowych tokenów jest używanych w środowisku naturalnym przez serwery lub klientów:

  • bzip2 – kompresja oparta na darmowym formacie bzip2, obsługiwana przez lighttpd
  • lzma – kompresja oparta na (surowej) LZMA jest dostępna w Operze 20, a w elinkach poprzez opcję kompilacji
  • peerdist — buforowanie i pobieranie zawartości równorzędnej firmy Microsoft
  • rsync - kodowanie delta w HTTP , zaimplementowane przez parę serwerów proxy rproxy .
  • xpress — protokół kompresji firmy Microsoft używany w systemie Windows 8 i nowszych do aktualizacji aplikacji Sklepu Windows. Kompresja oparta na LZ77 opcjonalnie przy użyciu kodowania Huffmana.
  • xz - kompresja treści oparta na LZMA2, obsługiwana przez nieoficjalną łatkę do Firefoksa; i w pełni wdrożony w mget od 2013-12-31.

Serwery obsługujące kompresję HTTP


Kompresja w HTTP może być również osiągnięta przy użyciu funkcjonalności języków skryptowych po stronie serwera , takich jak PHP , lub języków programowania, takich jak Java .

Problemy uniemożliwiające korzystanie z kompresji HTTP

Artykuł z 2009 roku autorstwa inżynierów Google, Arvinda Jaina i Jasona Glasgow, stwierdza, że ​​ponad 99 osobolat marnuje się dziennie z powodu wydłużenia czasu ładowania strony, gdy użytkownicy nie otrzymują skompresowanej treści. Dzieje się tak, gdy oprogramowanie antywirusowe zakłóca połączenia, aby wymusić ich dekompresję, gdy używane są serwery proxy (w przypadku zbyt ostrożnych przeglądarek internetowych), gdy serwery są źle skonfigurowane i gdy błędy przeglądarki zatrzymują kompresję. Internet Explorer 6, który spada do HTTP 1.0 (bez funkcji, takich jak kompresja lub potokowanie), gdy znajduje się za serwerem proxy – powszechna konfiguracja w środowiskach korporacyjnych – był główną przeglądarką najbardziej podatną na powrót do nieskompresowanego protokołu HTTP.

Inny problem wykryty podczas wdrażania kompresji HTTP na dużą skalę wynika z definicji kodowania deflate : podczas gdy HTTP 1.1 definiuje kodowanie deflate jako dane skompresowane przy użyciu deflate (RFC 1951) w strumieniu sformatowanym w zlib (RFC 1950), serwer i produkty klienckie firmy Microsoft są historycznie zaimplementował go jako „surowy” strumień z deflacją, przez co jego wdrożenie było zawodne. Z tego powodu niektóre programy, w tym Apache HTTP Server, implementują tylko kodowanie gzip .

Implikacje dla bezpieczeństwa

Główne artykuły: PRZESTĘPCZOŚĆ i NARUSZENIE

Kompresja umożliwia wykonanie wybranego ataku zwykłego tekstu : jeśli atakujący może wstrzyknąć dowolną wybraną treść na stronę, może wiedzieć, czy strona zawiera daną treść, obserwując wzrost rozmiaru zaszyfrowanego strumienia. Jeśli wzrost jest mniejszy niż oczekiwany dla losowych wstrzyknięć, oznacza to, że kompresor znalazł w tekście powtórzenie, tj. wstrzyknięta treść nakłada się na tajne informacje. To jest idea stojąca za CRIME.

W 2012 roku ogłoszono ogólny atak na stosowanie kompresji danych, zwany CRIME . Chociaż atak CRIME może skutecznie działać przeciwko dużej liczbie protokołów, w tym między innymi TLS i protokołom warstwy aplikacji, takim jak SPDY lub HTTP, tylko exploity przeciwko TLS i SPDY zostały zademonstrowane i w dużej mierze ograniczone w przeglądarkach i serwerach. Exploit CRIME przeciwko kompresji HTTP nie został w ogóle złagodzony, mimo że autorzy CRIME ostrzegali, że ta luka może być nawet bardziej rozpowszechniona niż kombinacja kompresji SPDY i TLS.

W 2013 roku opublikowano nową instancję ataku CRIME na kompresję HTTP, nazwaną BREACH. Atak BREACH może wydobyć tokeny logowania, adresy e-mail lub inne poufne informacje z ruchu internetowego zaszyfrowanego TLS w zaledwie 30 sekund (w zależności od liczby bajtów do wyodrębnienia), pod warunkiem, że atakujący nakłoni ofiarę do odwiedzenia złośliwego łącza internetowego. Wszystkie wersje TLS i SSL są zagrożone przez BREACH, niezależnie od zastosowanego algorytmu szyfrowania lub szyfru. W przeciwieństwie do poprzednich przypadków CRIME , przed którymi można skutecznie się bronić, wyłączając kompresję TLS lub kompresję nagłówków SPDY, BREACH wykorzystuje kompresję HTTP, której nie można realistycznie wyłączyć, ponieważ praktycznie wszystkie serwery internetowe polegają na niej w celu zwiększenia szybkości transmisji danych dla użytkowników.

Od 2016 r. atak TIME i atak HEIST są obecnie powszechnie znane.

Bibliografia

Linki zewnętrzne