Zaufane proxy w HTTP/2.0, czyli dostawca Internetu zajrzy w zaszyfrowane dane

Osobom troszczącym się o bezpieczeństwo sieci i zaniepokojonymskalą, na jaką prowadzona jest dziś inwigilacja Internetu musiałasię zapalić czerwona lampka na widok szkicu dokumentu *ExplicitTrusted Proxy in HTTP/2.0, którykilka dni temu trafił do Internet Engineering Task Force,organizacji zajmującej się standaryzacją rozwiązań technicznychstosowanych w Sieci. Tak przynajmniej zareagował znany aktywista ikonsultant Google Laureen Weinstein, nazywającwspomniany dokument jedną z najbardziej alarmującychpropozycji, *jakie widział.

Prace nad protokołem HTTP/2.0,następcą obecnie stosowanego protokołu hipertekstu HTTP 1.1,bazującego na google'owym SPDY, trwają już od kilku lat – ijeśli wszysko pójdzie zgodnie z planami, to zakończą się wlistopadzie tego roku. Przyjęcie HTTP/2.0 jako standardu będziewielkim krokiem naprzód w stronę szybszego i bezpieczniejszegoInternetu, przynosząc przede wszystkim takie ulepszenia jakpriorytetyzacja i multipleksacja połączeń serwer/przeglądarka,szyfrowanie wszystkich połączeń przez TLS i ich kompresowanieprzez gzip.

Jeśli przedstawiona wkontrowersyjnymszkicu propozycja trafi do standardu, to HTTP/2.0 przyniesiejeszcze coś – możliwość automatycznego deszyfrowania ruchusieciowego HTTPS przez zaufane proxy.Propozycję można streścić następująco: skoro od dawnawykorzystuje się serwery proxy do buforowania ruchu sieciowego,dając w ten sposób internautom szybszy dostęp do zasobów, adostawcom usług oszczędność w postaci zmniejszenia generowanegoprzez nich ruchu, to czemu rezygnować z tej praktyki w sytuacji, gdyruch będzie zaszyfrowany?

Problem jednak w tym, żeniemożliwość wejrzenia w zaszyfrowany ruch sieciowy uniemożliwiastosowanie wielu dotychczasowych strategii buforowania. Autorzyszkicu proponują więc wprowadzenie rozróżnienia międzypołączeniami HTTP2, które miałyby transportować zasoby „https”i połączeniami HTTP2, które transportowałyby połączenia „http”.Odbywać by się to miało za pomocą nowej wartości widentyfikatorze APLN – rozszerzenia do negocjacji warstwyaplikacyjnej protokołu. Wartość *h2clr *miałabyoznaczać, że HTTP2 stosowane jest do transportu zasobów „http”i jako takie może zostać odszyfrowane przez proxy.

Oznacza to, że nowy standardumożliwiłby (za zgodą użytkowników) zaufanym pośrednikom, takimjak ISP, na deszyfrowanie ruchu, przetworzenie go pod kątem lepszegobuforowania, ponownego zaszyfrowania i przekazania dalej, dodocelowego miejsca. Weinstein jest oburzony samą sugestią, że takąpraktykę usprawiedliwiałoby uzyskanie zgody użytkowników –zwykli użytkownicy nie są przecież w stanie podejmowaćracjonalnych decyzji w kwestiach technicznych. I rzeczywiście,wydaje się, że widząc komunikat dostawcy Internetu *Łączącsię z naszą siecią wyrażasz zgodę na to, by twój ruch sieciowybył przetwarzany celem zapewnienia szybszych połączeń, *ZwykłyUżytkownik po prostu kliknie „OK”, nie zdając sobie sprawę ztego, że w ten sposób ujawnia swojemu dostawcy Internetu (ikażdemu, kto patrzy zza jego ramienia) całą swoją poufnąkomunikację.

Nieco zabawnie w tej sytuacjiwyglądają twierdzenia autorów szkicu, że takie zaufaneproxy jest lepsze, niżprzeprowadzanie przez dostawców Internetu zautomatyzowanych atakówman-in-the-middle, by utrzymać działanie swoich proxy. Jakstwierdził Weinstein, przypomina to argumentowanie, że wykonaniekary śmierci przez zastrzyk z trucizną jest mniej okrutne, niż zapomocą krzesła elektrycznego. Z technicznego punktu widzenia toprawda – ale tak czy inaczej ofiara procedury umiera.

Z drugiej strony faktycznie mamyproblem z HTTP/2.0, psującym infrastrukturę buforowania ruchusieciowego, i nic dziwnego, że dostawcy Internetu próbują coś ztym zrobić (przedstawiony dokument jest sponsorowany przez AT&Ti Ericssona). Dla ISP już dzisiaj nie jest wielkim problememwprowadzić do przeglądarek użytkowników sfałszowane certyfikatydla popularnych witryn (może nawet z gotowym instalatorem dlaWindows?). Nowa wersja HTTP tego nie zmieni. Być może właściwądrogą byłoby wprowadzenie odrębnego mechanizmu do szyfrowaniafaktycznie poufnych danych, np. haseł logowania, uniemożliwiając wten sposób ich przejęcie przez „zaufane” proxy. Cała resztamogłaby być szyfrowana i deszyfrowana na bieżąco – niewielezmienia dla prywatnego użytkownika to, że jego ISP będziewiedział, jakie to klipy na YouTube ogląda.