r   e   k   l   a   m   a
r   e   k   l   a   m   a

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

Strona główna AktualnościINTERNET

Osobom troszczącym się o bezpieczeństwo sieci i zaniepokojonym skalą, na jaką prowadzona jest dziś inwigilacja Internetu musiała się zapalić czerwona lampka na widok szkicu dokumentu Explicit Trusted Proxy in HTTP/2.0, który kilka dni temu trafił do Internet Engineering Task Force, organizacji zajmującej się standaryzacją rozwiązań technicznych stosowanych w Sieci. Tak przynajmniej zareagował znany aktywista i konsultant Google Laureen Weinstein, nazywając wspomniany dokument jedną z najbardziej alarmujących propozycji, 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 – i jeśli wszysko pójdzie zgodnie z planami, to zakończą się w listopadzie tego roku. Przyjęcie HTTP/2.0 jako standardu będzie wielkim krokiem naprzód w stronę szybszego i bezpieczniejszego Internetu, przynosząc przede wszystkim takie ulepszenia jak priorytetyzacja i multipleksacja połączeń serwer/przeglądarka, szyfrowanie wszystkich połączeń przez TLS i ich kompresowanie przez gzip.

Jeśli przedstawiona w kontrowersyjnym szkicu propozycja trafi do standardu, to HTTP/2.0 przyniesie jeszcze coś – możliwość automatycznego deszyfrowania ruchu sieciowego HTTPS przez zaufane proxy. Propozycję można streścić następująco: skoro od dawna wykorzystuje się serwery proxy do buforowania ruchu sieciowego, dając w ten sposób internautom szybszy dostęp do zasobów, a dostawcom usług oszczędność w postaci zmniejszenia generowanego przez nich ruchu, to czemu rezygnować z tej praktyki w sytuacji, gdy ruch będzie zaszyfrowany?

r   e   k   l   a   m   a

Problem jednak w tym, że niemożliwość wejrzenia w zaszyfrowany ruch sieciowy uniemożliwia stosowanie wielu dotychczasowych strategii buforowania. Autorzy szkicu proponują więc wprowadzenie rozróżnienia między połą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 w identyfikatorze APLN – rozszerzenia do negocjacji warstwy aplikacyjnej protokołu. Wartość h2clr miałaby oznaczać, że HTTP2 stosowane jest do transportu zasobów „http” i jako takie może zostać odszyfrowane przez proxy.

Oznacza to, że nowy standard umożliwiłby (za zgodą użytkowników) zaufanym pośrednikom, takim jak ISP, na deszyfrowanie ruchu, przetworzenie go pod kątem lepszego buforowania, ponownego zaszyfrowania i przekazania dalej, do docelowego 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ąc się z naszą siecią wyrażasz zgodę na to, by twój ruch sieciowy był przetwarzany celem zapewnienia szybszych połączeń, Zwykły Użytkownik po prostu kliknie „OK”, nie zdając sobie sprawę z tego, że w ten sposób ujawnia swojemu dostawcy Internetu (i każdemu, kto patrzy zza jego ramienia) całą swoją poufną komunikację.

Nieco zabawnie w tej sytuacji wyglądają twierdzenia autorów szkicu, że takie zaufane proxy jest lepsze, niż przeprowadzanie przez dostawców Internetu zautomatyzowanych ataków man-in-the-middle, by utrzymać działanie swoich proxy. Jak stwierdził Weinstein, przypomina to argumentowanie, że wykonanie kary śmierci przez zastrzyk z trucizną jest mniej okrutne, niż za pomocą krzesła elektrycznego. Z technicznego punktu widzenia to prawda – ale tak czy inaczej ofiara procedury umiera.

Z drugiej strony faktycznie mamy problem z HTTP/2.0, psującym infrastrukturę buforowania ruchu sieciowego, i nic dziwnego, że dostawcy Internetu próbują coś z tym zrobić (przedstawiony dokument jest sponsorowany przez AT&T i Ericssona). Dla ISP już dzisiaj nie jest wielkim problemem wprowadzić do przeglądarek użytkowników sfałszowane certyfikaty dla popularnych witryn (może nawet z gotowym instalatorem dla Windows?). Nowa wersja HTTP tego nie zmieni. Być może właściwą drogą byłoby wprowadzenie odrębnego mechanizmu do szyfrowania faktycznie poufnych danych, np. haseł logowania, uniemożliwiając w ten sposób ich przejęcie przez „zaufane” proxy. Cała reszta mogłaby być szyfrowana i deszyfrowana na bieżąco – niewiele zmienia dla prywatnego użytkownika to, że jego ISP będzie wiedział, jakie to klipy na YouTube ogląda.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.