Firma Google ogłosiła niedawno, że wyłączy tzw. webRequest API w wersjach Chrome, które ukażą się w przyszłym roku. Interfejs ten umożliwia filtrowanie treści internetowych. Podobny ruch zapowiedział Microsoft. Wyłączenie API sprawia, że skuteczne filtrowanie treści internetowych jest praktycznie niemożliwe – z poważnymi konsekwencjami m.in. dla rozwiązań bezpieczeństwa.
Powody filtrowania stron internetowych
Istnieje wiele powodów filtrowania treści internetowych. Rozwiązania bezpieczeństwa takie jak G DATA Total Security zapewniają ochronę przed złośliwym oprogramowaniem, phishingiem oraz odnośnikami do stron wykradającymi dane. Z drugiej strony, filtrowanie może być stosowane w celu egzekwowania przestrzegania przepisów obowiązujących w firmach, na przykład w celu zapobiegania przeglądaniu stron internetowych z grami.
Ponadto istnieje zrozumiała chęć ze strony szkół i rodziców, aby uniemożliwić nieletnim dostęp do stron internetowych nieodpowiednich ze względu na wiek. Należą do nich na przykład strony internetowe o charakterze pornograficznym, strony o charakterze politycznym oraz treści zachęcające do niebezpiecznych zachowań, takich jak anoreksja, samookaleczenie, a nawet samobójstwa. Wreszcie, najczęstszą przyczyną filtrowania przez użytkowników końcowych jest blokowanie reklam .
Biznes?
Powodem wyłączenia interfejsu mogą być adblockery. Wynika to z faktu, że blokery reklam działają w całkowitej sprzeczności z modelem biznesowym dostawcy przeglądarki Chrome – Google. Gigant z Mountain View generuje miliardy dolarów rocznych przychodów głównie ze sprzedaży reklam. Dla porównania, średni obrót generowany przez Google z reklamy jest wyższy niż produkt krajowy brutto takich krajów jak Ukraina, Słowacja czy Luksemburg!
Man in the middle? Nie, dziękuję!
Zamiast używać odpowiednich interfejsów API, różni dostawcy mechanizmów filtrujących, tacy jak dostawcy zabezpieczeń, wdrażają certyfikaty „man-in-the-middle”. Dzięki temu certyfikat bezpieczeństwa faktycznie wykorzystywany przez stronę internetową jest ostatecznie zastępowany przez oprogramowanie dostawcy, tak aby przekazywane treści mogły być odczytywane razem z nim.
Zasada jest podobna do tej stosowanej przez przestępców w celu uzyskania dostępu do danych bez uprawnień. Dlatego też w G DATA odrzucamy tę metodę ze względów bezpieczeństwa, gdyż niepotrzebnie przerywa ona łańcuch bezpieczeństwa i tym samym stwarza potencjalną lukę dla szkodliwego oprogramowania.
Leniwe kompromisy
Google nie dostarcza realnej alternatywy dla zablokowanych rozwiązań. Ogólną rekomendacją jest korzystanie z API declarativeNetRequest. Problem polega na tym, że to API umożliwia jedynie dopasowanie żądań użytkowników do listy adresów URL. Zgodnie z aktualną dokumentacją Google, lista ta jest ograniczona do 30000 wpisów, przy czym wg. Google planuje zwiększyć listę do 150000 pozycji.
Z drugiej strony mamy przykład złośliwego oprogramowanie „Conficker”, które pojawiło się dekadę temu i generuje do 50000 domen dziennie przy użyciu tak zwanego „Algorytmu generowania domen” (DGA). Na tej podstawie skuteczne blokowanie poprzez listę statycznych wpisów URL mogło być możliwe i skuteczne 20 lat temu, ale nie jest to wystarczające rozwiązanie dla współczesnych potrzeb.
DNS jako filtr?
Zasadniczo, rozwiązania zabezpieczające mogłyby filtrować zagrożenie wcześniej niż poprzez badanie adresów URL w samej przeglądarce. Byłoby to związane z rozpoznawaniem zapytań użytkowników do dostawców sieci za pośrednictwem systemu obsługi nazw domen. Ale tutaj znowu miałby miejsce daleko idące zmiany, które niosłyby ze sobą konsekwencje dla bezpieczeństwa i prywatności użytkowników.
Oprócz wyeliminowania skutecznych mechanizmów bezpośredniego filtrowania, dostawcy przeglądarek konwertują domyślne rozwiązywanie nazw DNS na szyfrowany protokół „DNS over HTTPS” (DoH). Dostawca przeglądarek Mozilla testuje obecnie podobną usługę od CDN Cloudflare w swojej przeglądarce Firefox. Usługa jest reklamowana jako dodatkowy „środek bezpieczeństwa”, ponieważ zapytania DNS są teraz przesyłane w zaszyfrowanej formie. Zaszyfrowane zapytania DNS od lat są przedmiotem dyskusji – ostatnio dostawcy domagają się wdrożenia standardu DNSSec, chociaż nie zostało to przyjęte przez użytkowników prywatnych.
Wręcz przeciwnie: Użytkownicy prywatni i mniejsze firmy zazwyczaj korzystają z resolwera swojego dostawcy. Zapytania DNS nie opuszczają zatem sieci dostawcy. Wraz z wprowadzeniem systemu DoH, dostawca – który w przypadku Europy przestrzega europejskich przepisów i koncepcji dotyczących ochrony danych – jest skutecznie i bez przeszkód pomijany. Większe firmy zazwyczaj posiadają własne resolwery DNS. Byłoby to również przedmiotem naruszenia, a dane DNS byłyby udostępniane stronom trzecim – zazwyczaj w USA. Istnieje również możliwość, że lokalne rekordy DNS, takie jak domeny intranetowe, mogłyby wyciekać do dostawców DoH. Zasadniczo zainteresowani użytkownicy nie podpisaliby umowy z odpowiednimi dostawcami usług.
Stałe korzystanie z zaszyfrowanych zapytań DNS nie jest konieczne dla wszystkich użytkowników. Użytkownicy, którzy zasadniczo nie ufają własnym ISP – jak ci w państwach totalitarnych – wykazują większe zainteresowanie takim rozwiązaniem. Korzyścią może być również bezpieczeństwo i prywatność w publicznych sieciach WLAN. Dla użytkowników prywatnych lub osób działających w środowisku biznesowym DoH nie oferuje obecnie żadnej wartości dodanej.
Naszym zdaniem brak jakiejkolwiek wartości dodanej to w zasadzie przeciwdziałanie i eliminowanie ryzyka. Resolwery DNS używane przez Mozillę wymuszają na partnerach spełnienie określonych warunków. Umożliwiają one jednak osobiste przechowywanie DNS przez jeden dzień i nie nakładają żadnych dodatkowych wymogów dotyczących użytkowania – z wyjątkiem tego, że dane osobowe nie mogą być przekazywane dalej. Szczególnie interesujące jest jednak to, że wykorzystywanie resolwera do celów reklamowych nie jest zabronione.
Microsoft ogłosił ostatnio również, że będzie używał DoH w systemie Windows. Jednak tylko serwer DNS skonfigurowany przez użytkownika lub administratora jest sprawdzany pod kątem zgodności z DoH. Żaden inny serwer DoH nie jest skonfigurowany w sposób automatyczny, tak jak w przypadku dostawców przeglądarek.
Kto będzie się zajmował ochroną?
Dzięki Google Safe Browsing, Google umożliwia sobie to czego nie mogą zrobić inni dostawcy zabezpieczeń. Google może czytać listy filtrów dostawców plug-inów dla Chrome i wykorzystywać je do własnych celów. W ten sposób Google stałoby się de facto monopolistą w dziedzinie list filtrujących, ponieważ niezależni dostawcy straciliby dużą część swojej działalności.
Jest to więcej niż wątpliwe w świetle prawa do konkurencji. Ponadto wszyscy użytkownicy Internetu znajdą się wtedy na łasce i niełasce amerykańskiej firmy z wszystkimi konsekwencjami w zakresie ochrony danych i bez możliwości monitorowania lub wyboru alternatywy. Zrozumienie, że taka wymuszona restrukturyzacja jest szkodliwa dla współczesnego Internetu nadal wydaje się nie być zjawiskiem powszechnym.
Wniosek
Z tego względu w G DATA deklarujemy, że Google i Mozilla naciskają obecnie na zmiany w swoich produktach z czysto biznesowych powodów – ukrytych za małym retorycznym listkiem figowym o ochronie danych osobowych i prywatności. Korzyści dla użytkowników nie są w tej chwili jasne, ponieważ tylko przenoszą one problem dotyczący zaufania, przykładowo dla protokołu DoH w inne miejsce.
