11:41
22/5/2010

Szyfrowane Google to ściema?

Od dziś Google można odpytywać po “bezpiecznym protokole” HTTPS. Wątpimy, że SSL przy wyszukiwaniu jest zbawieniem dla wszystkich internautów, ale w kilku sytuacjach może być przydatny. Poniżej pokazujemy jak dowiedzieć się, co dana osoba wpisała w “Bezpieczne Google” mimo tego, że połączenie jest szyfrowane i “nie do podsłuchania”.

Google: HTTPS i SSL

Aby skorzystać z wyszkiwarki po SSL-u trzeba udać się na stronę https://www.google.com (niestety na razie klepanie “www” jest niezbędne).

Szyfrowana wyszukiwarka Google

Na stronie wyszukiwarki nie zobaczymy linków do innych usług Google (żeby przypadkiem nie “wyciec” naszego zapytania do nieszyfrowanych Maps, Images czy Video.

Eksperyment #1: Zbędny SSL

Szczerze mówiąc, nie bardzo rozumiemy wprowadzenie możliwości “poufnego” wyszukiwania, bo z poufnością wyszukiwanie w Google, czy to po SSL-u, czy bez, nie ma zbyt wiele wspólnego…

Raz, że Google i tak wie, czego szukamy (i dalej odkłada logi “celem ulepszenia silnika sugestii”). Dwa, że klikając na wyniki wyszukiwania, opuszczamy protokół HTTPS i potencjalny podsłuchiwacz i tak dowie się, czego dotyczy oglądana przez nas strona.

Nie wierzycie? Spróbujcie odgadnąć co “ofiara” wpisała w Google, jeśli sniffer pokazuje wam, że ofiara odwiedziła (w krótkim czasie po sobie) poniższe strony:

http://pl.wikipedia.org/wiki/Zaparcie
http://www.zaparcie.pl/
http://zdrowie.gazeta.pl/zdrowie/2,51172,,,,37394035,P_MEDIMEDIA_CHOROBY.html

Rany, straszne trudne, nie? :-)

Małe, nieużyteczne ulepszenie

Jeśli mówimy o poufności komunikacji w kontekście HTTPS to większy sens miałoby zezwolenie na wyszukiwanie tylko i wyłącznie stron, które HTTPS wspierają… Ale ile zwykłych serwisów jest dostępnych po HTTPS?

No i kolejna przeszkoda: jak często mając serwis wspierający HTTPS można wywnioskować czego on dotyczy po samych tylko słowach w adresie URL?. No właśnie… taka specyfika protokołu i cieżko coś z tym zrobić.

  • https://weneryczne.choroby.biz/

Władku, jak mogłeś!?

Eksperyment #2 – Nicniedający SSL

To teraz drugi eksperyment. W podsłuchanym ruchu sieciowym widzicie, że ofiara odwiedziła stronę: nastolatki.pl. Jakie mogła zadać pytanie? Czy tylko nasuwające się na myśl “nastolatki“?

Zakładając, że 90% osób po wpisaniu w wyszukiwarkę zapytania klika na jeden z pierwszych trzech wyników

W co klikamy na stronach z wynikami Google?

…wpiszmy adres odwiedzonej strony do narzędzia, które pokazuje nam słowa kluczowe związane z danym serwisem oraz jego pozycję dla tych słów.

Tego się po tobie nie spodziewałam Waldemarze! -- powie zasmucona żona do męża

Zastanówcie się tylko czy mając w garści ruch do stron, w ogóle potrzebujemy słów kluczowych, które ofiara wpisała w Google?

A może jednak Google po SSL się przyda?

Naprawdę chcąc uzasadnić skorzystanie z wyszukiwarki po SSL-u, po długim namyśle, doszliśmy do takiej, dość wydumanej sytuacji:

Na spotkanie osób zainteresowanych bezpiecznym pisaniem webaplikacji PSAWO (Polskie Stowarzyszenie Atakowania Webaplikacji Okolicznych) zaproszono przedstawiciela firmy AI Rogella — dużej platformy sprzedażowej. W trakcie prezentacji pada pytanie, z jakiego frameworka korzysta ta firma do pisania swojego kodu… Przedstawiciel odmawia odpowiedzi zasłaniając się procedurami bezpieczeństwa i tajemnicą firmy.

Pod koniec pada kolejne pytanie, czy wykorzystywany framework umożliwia np. wsparcie dla OpenID? Prelegent nie wie, ale pytanie wydaje mu się na tyle ciekawe, że pierwsze co robi po prezentacji to wpisuje do Google: “TajnyFramework OpenID support“, sprawdzając, że w wykorzystywanym przez jego firmie frameworku OpenID jest (bądź nie jest) wspierane. Słuchacze oczywiście sniffują publicznego HotSpota i już mają odpowiedź na pytanie, z jakich rozwiązań korzysta firma AI Rogella.

Dlaczego dość wydumana to historia? Bo prelegenci PSAWO to w końcu osoby związane z bezpieczeństwem i chcąc zachować swoją prywatność albo stunelują się po VPN, albo skorzystają ze swojego korporacyjnego modemu i sieci GSM

PR i nic więcej?

Podsumowując, mamy wrażenie, że szyfrowanie samego wyszukiwania niczego nie zmienia i patrząc na powyższe eksperymenty bardziej niż poziom prywatności internautów raczej podnosi PR dla Google. Ale zawsze lepiej móc więcej niż mniej…

W “Szyfrowanym Google” widzielibyśmy więcej sensu, gdyby udostępniany przez Google “cache stron” również był dostępny po HTTPS — ale jak narazie, nie jest.

Aktualizacja 22.05.2010 13:30
Właśnie zauważyliśmy plus HTTPS-u w Google — co prawda nie techniczny, a polityczny… Chodzi o zwiększenie świadomości “szyfrowania połączeń” wśród właścicieli serwisów internetowych — miejmy nadzieję, że “agitacja” Google skłoni kilka serwisów do udostępnienia HTTPS-u.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

41 komentarzy

Dodaj komentarz
  1. To może teraz jakiś artykuł o tym jak naprawdę bezpiecznie wyszukiwać w Google? ;]

  2. Ze swojej strony polecam poniższy plugin do Firefox’a:

    http://www.googlesharing.net/

    Mała rzecz – a cieszy.

  3. Jest jeden “plus” tego jaki widzę, nie można blokować niektórych keywordsów przepuszczając innych, ani oskarżać kogoś o szukaniu “złych rzeczy”. Tyle że gdy zaczyna działać cenzura na taką skalę zwykle po prostu blokuje google w całości.

    • @XANi jeśli chodzi o środowiska korporacyjne, to instpekcja SSL jest teraz w prawie każdym poważniejszym “security appliance”…

  4. OkropNick, ta wtyczka dotyczy chyba tylko google.com.

  5. @OkropNick – a to nie jest tak, że Google nie pozna naszych zapytań, za to będzie nimi dysponowała ta firma ? ;]

  6. “https://weneryczne.choroby.biz/rzerzaczka”, usuncie /rzerzaczka.

    W https, mozna podsluchac nazwe domeny, ale na pewno nie dokumentu.

  7. A moim zdaniem to słuszny krok – nawet jeśli zysk pod kątem bezpieczeństwa jest pomijalnie mały – przynajmniej da to do myślenia wielu twórcom stron WWW – że SSL/TLS to nie tylko tak dla banków, ale też dla zwykłej komunikacji.

  8. @Torwald: Być może będzie miała, ale z dwojga złego wolę taką opcję. Google już i tak za dużo wie.

  9. zawsze pozostaje jeszcze sslstrip :)

  10. @Kamil: Dziękujemy za przepisanie nam ostatniego akapitu w komentarzach… *facepalm*

  11. Z HTTPS-owego Google właściciele witryn, na które lądujesz, nie dostaną Referera.

    • @pambuk: No i? Bo to jest standard w (chyba wszystkich?) przeglądarkach przy przełażeniu z HTTPS na HTTP.

  12. @Torwald, @OkropNick – nawet nie zbadaliście technologii przed rzuceniem się na nią. :> O swoim Google Sharing opowiadał Moxie Marlinspike na Blackhat DC 2010. To sieć proxies przeznaczonych specjalnie i tylko do guglania, ale i samemu można założyć własny węzeł. Wygląda na bardziej zdecentralizowane niż np. Scroogle. Oczywiście proxies kasują słynne Ciastko 2037, choć nie wiem, dokładnie co ile zapytań tunelujesz się przez nowe proxy.

  13. Jako zaletę to dodaję – że do czegoś komuś potencjalnie może to służyć. Chociaż jak ktoś tak analny i świadom Refererów, a nie chce ich gdzieś zostawić (dajmy na to agent rekrutacji screenujący człowieka po imieniu i nazwisku w Google albo co gorsza jakiś egosurfer) to sobie skopiuje link i wklei. Dyskutować można, że webmasterzy dzięki danym z Refererów lepsze strony dla nas robią. Oczywiście uwaga ta nie neguje wszystkich ładnie opisanych problemów z własnym ruszaniem się po sieci Web.

  14. A najśmieszniejsze w tej historii jest umieszczenie znaczka *beta*

    ROTFL

  15. Warto pamiętać o dwóch sprawach:
    – szyfrowany ruch jest na całej trasie czyli w sytuacji gdy podsłuchujący jest podłączony bezpośrednio do naszej sieci, przy naszej ostatniej mili faktycznie to zabezpieczenie nie wiele daje ALE na całej pozostałej drodze od nas do serwerów google – nie jest możliwe podsłuchanie transmisji zadawanych zapytań i myślę, że to jest tutaj sednem sprawy. Pamiętajmy, że podsłuchiwanie to nie tylko źle zabezpieczone WiFi sąsiada…
    – teoretycznie bardzo szalony świadomy użytkownik, może być pewien, że odwiedza google.com i nie jest ofiarą ataku SEO phishingowego ;]

    PS: Pod Operą dostaję info po kliknięciu na pasku adresu w ikonę zabezpieczeń, że witryna nie jest bezpieczna…

  16. Obciążanie Google za to, że inne strony nie stosują protokołu https, to po prostu ostra paranoja.

  17. @Matsukawa: nie wiem skąd wyciągnąłeś taki wniosek… Tu nikt nie oskarża Google za błędy, czy braki innych serwisów ;-) Po prostu uważamy, że wdrożenie SSL dla Google Search na dzień dzisiejszy nie daje Kowalskiemu żadnej konkretnej wartości dodanej (czyt. nie zapewnia poufności komunikacji w przypadkach sniffingu z LAN-u i nie podnosi “bezpieczeństwa” połączenia). Jedynym plusem jest zapewnienie integralności (pomijalna właściwość z punktu bezpieczeństwa) i polityczny lobbing/reklama rozwiązań SSL-owych (Szef: Panie Janku, Google ma SSL-a! Zrób pan i u nas na stronie!).

  18. Będąc zalogowanym do konta Google, w prawym górnym rogu pojawia się nazwa użytkownika, czyli podsłuchując można poznać gmailowy adres e-mail podsłuchiwanego.

  19. @Piotr Konieczny: Wdrożenie SSL dla Google Search, owszem, daje i to sporo, choć może nie przeciętnemu Kowalskiemu, a osobom, które używają wyszukiwarki Google w ramach swojego zawodu. Wyszukiwarka ta pozwala przecież nie tylko kierować na docelowe strony, ale także np. przeszukać strony, w których użytkownik już kiedyś szperał i pozostały zapisane w jego historii poszukiwań. Nie są to wiadomości, które chętnie by się udostępniało szerokiemu gremium, ponieważ o wiele bardziej niż inne świadczą o naszych preferencjach.

    Usługa jest jeszcze w powijakach; przypuszczam że w przyszłości Google zastosuje podobny sposób przeglądania rozmaitych dokumentów (.pdf, .doc, .odt), zarchiwizowanych kopii stron, innych swoich usług takich jak blog, youtube, book, a także materiałów przeglądanych “w ramce” i to nie tylko graficznych. Sądzę, że to ostatnie zastosowanie zadowoli wszystkich krytyków…

    • @Matsukawa: zechcesz rozwinąć jak wdrożenie SSL do Google Search pomogło uchronić się przed “przeszukać strony, w których użytkownik już kiedyś szperał i pozostały zapisane w jego historii poszukiwań”. W sensie, które z ataków pozwalających na dostęp do przytoczonych przez Ciebie danych były możliwe, a teraz nie są?

  20. @Piotr Konieczny: Od jakiego poziomu mam uzupełniać Twoją edukację?

  21. @Matsukawa: zapewniam Cię, że mojej edukacji uzupełniać nie musisz — warto by jednak było, żebyś udowodnił swoje tezy (zacytowałem je w poprzednim komentarzu). Argumentami ad personam nie zyskasz tutaj przewagi, na Niebezpieczniku dyskutujemy merytorycznie, a Ty jak narazie, oprócz enigmatycznej wypowiedzi sugerującej że “po wprowadzeniu SSL-a nie będzie można już wyciągać historii wyszukiwań” nie podałeś żadnych dowodów na to, że a) wcześniej się dało, b) a teraz z SSL się nie da. Ciągle czekamy na jakiś PoC… jeśli po prostu Ci się wymsknęło, OK, daj znać, zawsze możemy skasować komentarz na prośbę właściciela ;)

  22. BTW. Niebiezpiecznik tez oszczedza kilka zlotych na certa – szewc w dziurawych butach chodzi. (;

    • @Sokolowski: nie widzimy sensu stosowania SSL-a w naszhym przypadku. Chyba, że masz jakiś *mocny* argument :-) Większość naszych czytelników jeśli chce zachować poufność, wie w jaki sposób może nas czytać…

  23. […] Tak naprawdę Google z SSL nie jest aż tak bardzo bezpieczne, ale troszkę bezpieczniejsze, więcej do przeczytania dlaczego, tutaj. […]

  24. […] …ale nie na tym polega jej fail. BTW: do tego celu idealnie nadałby się SSL, który ostatnio tak mocno reklamowała Google, a którego implementacja akurat w przypadku Google nie do końca zapewnia “poufność” transmisji. […]

  25. @Piotr
    >Jedynym plusem jest zapewnienie integralności (pomijalna właściwość z punktu >bezpieczeństwa)

    Że co????? Spec od bezpieczeństwa marginalizuje jedną z 3 jego podstaw, chyba przestanę tu zaglądać. Rozumiem że poufność i dostępność to także pomijalne właściwości z punktu bezpieczeństwa.

    Mam pomysł, wyłączcie niebezpiecznik.pl, niech nie będzie dostępny skoro poufny nie jest, a intergralność to pomijalna właściwość.

    • dzikus: Integralność *w tym przypadku* ochrania cię tylko przed wstrzyknięciem treści w wyniki wyszukiwania — np. reklam przez twojego ISP. Z punktu widzenia bezpieczeństwa i obecnej sytuacji (żaden z ISP tego nie robi) ryzyko jest pomijalne. Rozumiem, że zauważyłeś iż, rozmawiamy na temat TYLKO TEGO konkretnego przypadku, prawda? Tak więc twoja alegoria do przelewów internetowych nadaje się tylko na *facepalm* i lrn2read! (BTW, w przypadku Google także poufność jest pomijalna, bo pokazałem, dlaczego szyfrowanie w Google Search nie ma sensu i jak można się domyślić, o co pytał użytkownik).

  26. Tak jeszcze tylko dorzucę, że proponuję we wszelkich przelewach bankowych Piotra K. pominąć integralność i podmienić numer konta docelowego na mój :P.

  27. […] między innymi w tekście o ryzyku korzystania z Googlowych DNS-ów, a także w artykule pt. szyfrowanie w Google to ściema oraz przy opisywaniu niedawnej afery związanej ze zbieraniem przez Google informacji z sieci […]

  28. Błagam, SSL się obsługuje, a nie wspiera.
    http://sjp.pwn.pl/slownik/2535317/wesprze%C4%87

  29. Spójrzcie na to:
    https://encrypted.google.com/search?hl=pl&source=hp&q=abc

    ktoś widząc taki adres wie że szukaliśmy “abc” (q=abc)

    Wszystko więc widać…

  30. @tester0x: Nie prawda. Dlatego, że ktoś podsłuchujący transmisję szyfrowaną – nie widzi tego adresu. Nie piszemy tutaj o ludziach, którzy patrzą Ci na monitor i klawiaturę bo zupełnie nie do tego szyfrowanie transmisji służy :]

  31. A jaki adres widzi? Po co więc google tworzy taki adres? Scroogle nie robi takiej zmyłki – nie widać nic w adresie.

  32. Man-in-the-middle, przy zwykłym HTTP można go wykonać bez bólu, podmiana wyników wyszukiwania ;) Przy HTTPS to bardziej skomplikowana sprawa.

  33. No dobrze, czyli wyszukiwarka zwraca nam strony, które nawet przez admina są nie widoczne czy dobrze rozumiem?? A co dalej? Jeśli wchodzimy w wyszukany link to dalej te połączenie jest szyfrowane czy już dalej jawne ??

  34. […] “szukaczy” jak nam się wydaje — analizując zaszyfrowany ruch internauty także można wiele wywnioskować. HTTPS nie gwarantuje […]

  35. Wydaje mi sie ze chodzi bardziej o ochrone szczegolow engine google. Przykladowo jak ktos wszedl na strone nastolatki to mozna zgadywac, ale nie wiadomo w 100% co dokladnie wpisal uzytkownik. A to jest istotne, konkurencja moglaby robic cos w stylu reverse engineering i probowac sciagnac algorytmy wyszukiwania (ktore sa raczej dosyc zaawansowane). Oczywiscie nic to nie da jesli np. w IE byloby logowanie slow-kluczy na poziomie aplikacji, nie mniej ruch google wydaje mi sie sensowny

  36. Szyfrowanie Google ma zupełnie inne znaczenie. Google szuka wystąpień cyklicznych, żeby nauczyć się łamać zabezpieczenia i uzyskać dostęp do danych z systemów zamkniętych. Miliardy transakcji w SSL pozwoli szybko znaleźć sposób na obecne algorytmy.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: