Przeglądanie stron internetowych na telefonie ciągle dużym wyzwaniem. Inna rozdzielczość, drogi transfer danych – to problemy, z którymi muszą sobie radzić użytkownicy. Pomagają producenci urządzeń – ale czasem robią to dość niezręcznie.
Gaurang Pandya, analityk zajmujący się kwestiami bezpieczeństwa, postanowił przyjrzeć się działaniu przeglądarki Xpress Browser, oferowanej wraz z jego Nokią Asha 302 (instalowanej dostępnej także w serii Lumia). Najpierw ustalił, że ruch HTTP jest przekierowywany na serwery Nokii, gdzie odpowiedzi serwerów www są kompresowane, by dzięki mniejszemu transferowi oszczędzić użytkownikom wysokich rachunków. Kolejnym pytaniem, które sobie zadał, było oczywiście „A co dzieje się z ruchem HTTPS?„. Odpowiedź nie była taka oczywista.
Najpierw przyjrzał się żądaniu DNS. Okazało się, że gdy próbował odwiedzić witrynę https://google.com, jego przeglądarka zaczęła szukać serwera cloud13.browser.ovi.com, czyli proxy Nokii. Zaniepokoiło go to na tyle, że przyjrzał się certyfikatom używanym do zaszyfrowania połączenia.
Okazało się, że witryna https://google.com używała certyfikatu Nokii, co jednoznacznie wskazuje na przechwytywanie ruchu SSL użytkownika przez serwer proxy (klasyczny atak MiTM). Co jeszcze gorsze, mimo, iż połączenie nawiązywane było z serwerem cloud13.browser.ovi.com, a certyfikat wystawiony był dla cloud1.browser.ovi.com, przeglądarka nie generowała żadnych ostrzeżeń. Brak ostrzeżeń może również oznaczać, że Nokia zainstalowała w telefonie swój certyfikat jako zaufany, dzięki czemu mogło dojść do ataku.
Oczywiście celem Nokii raczej nie jest szpiegowanie użytkowników (taką mamy przynajmniej nadzieję), a jedynie kompresowanie ich ruchu internetowego, jednak na stronie Nokii brak jakichkolwiek informacji o tym procederze. W polityce prywatności firmy nie znajdziemy ani informacji o tym, że ruch przeglądarki przechodzi przez serwery Nokii, ani tym bardziej o tym, że jest tam rozszyfrowany.
Nokia zapytana przez dziennikarzy przyznała, że faktycznie przechwytuje szyfrowane połączenia za pomocą podstawionych certyfikatów. Dodała jednocześnie, że oczywiście nikt z jej pracowników nie posiada dostępu do danych rozszyfrowanych, dane nie są zbierane ani przechowywane na jej serwerach a jedynym celem operacji jest zmniejszenie objętości transmitowanych danych. Podsumowując, użytkownicy nie mają się czym przejmować.
Pewnie niektórzy Czytelnicy zapytają „A czym się to różni od działania Opery Mini?”. Odpowiedź jest prosta – Opera wprost opisuje sposób funkcjonowania swojego rozwiązania, wskazując, że cały ruch między przeglądarką na telefonie a jej serwerami szyfruje swoim własnym algorytmem, wykorzystującym RC4 z kluczem 256-bitowym a wymianę kluczy zabezpiecza algorytmem RSA z kluczem o długości 1280 bitów. Sposób funkcjonowania Nokia Xpress Browser był do tej pory tajemnicą, nieznaną użytkownikom, przez co nie mogli oni sami podjąć świadomej decyzji, czy chcą z takiego rozwiązania korzystać.
Czy Nokia mogła zastosować inne rozwiązanie? Oczywiście tak – dobry przykład stanowi Amazon ze swoją przeglądarką Silk dla Kindle Fire, która choć prawie cały ruch przesyła przez amazonową chmurę, to ruchu SSL nie modyfikuje. Tak samo działa inna mobilna przeglądarka, Skyfire.
Autor odkrycia poinformował, że Nokia wypuściła nową wersję przeglądarki, która wydaje się tunelować ruch HTTPS po HTTP, co może oznaczać, że Nokia zaprzestała swoich „niewinnych” praktyk.
Komentarze
Czy ten sam mechanizm działa podczas korzystania z Wifi? Co z ruchem do stron z prywatnymi adresami IP (przez wifi)? Czy da się to wyłączyć?
Mateusz, a jak serwery Nokii miałyby się połączyć z tymi w Twojej prywatnej sieci?
Nie mamy jak przetestować, ale na 99% Xpress Browser działa tak przez WiFi (autor odkrycia inaczej nie mógłby raczej snifować ruchu). Można wyłączyć korzystając z innej przeglądarki :)
Autor tłumaczy w tekście, że sniffing wykonał lokalnie w sieci WiFi, a w 3G śledził pakiety po stronie swojego własnego serwera. W obu przypadkach ma miejsce MiTM.