Według Google różnica polega na obsłudze informacji o stronie odsyłającej po kliknięciu reklamy.

Po wiadomości od AviD i z pomocą Xandera przeprowadziliśmy kilka testów i oto wyniki

1. Kliknięcie reklamy:

• https://google.com : Google przeniesie Cię na stronę HTTP przekierowania gdzie dołączyliby Twoje zapytanie do informacji o stronie odsyłającej.

• https://encrypted.google.com : Jeśli reklamodawca używa protokołu HTTP, Google nie poinformuje reklamodawcy o Twoim zapytaniu. Jeśli reklamodawca korzysta z HTTPS, normalnie otrzyma informacje o stronie odsyłającej (w tym Twoje zapytanie).

2. Kliknięcie zwykłego wyniku wyszukiwania:

• https://google.com : Jeśli witryna korzysta z protokołu HTTP, Google przeniesie Cię do strona przekierowująca HTTP i nie będzie dołączać zapytania wyszukiwania do informacji o stronie odsyłającej. Poinformują tylko witrynę, że przechodzisz z Google. Jeśli używa HTTPS, normalnie otrzyma informacje o stronie odsyłającej.

• https://encrypted.google.com : Jeśli witryna, którą klikasz w wynikach, używa protokołu HTTP, nie będzie miała pojęcia, gdzie pochodzisz lub jakie jest Twoje zapytanie. Jeśli używa HTTPS, normalnie otrzyma informacje o adresie odsyłającym.

Ten sam temat został omówiony w poście na blogu EFF.

EDYCJA : Google usunęło encrypted.google.com 30 kwietnia 2018 r. Według Google ta domena była używana, aby umożliwić użytkownikom bezpieczne wyszukiwanie internet. Teraz wszystkie produkty Google i większość nowszych przeglądarek, takich jak Chrome, automatycznie używają połączeń HTTPS.

W chwili pisania tego tekstu (lipiec 2013 r.) obie witryny mają różne preferencje dotyczące algorytmów wymiany kluczy. Aby sprawdzić w przeglądarce Chrome, kliknij ikonę kłódki i wybierz kartę „połączenie”.

W porównaniu z przeglądarką Chrome 28, vanilla google.com używa ECDHE_RSA, a encrypted.google.com używa ECDHE_ECDSA. Oba algorytmy zapewniają poufność przekazywania. https://www.imperialviolet.org/2011/11/22/forwardsecret.html

Aby uzyskać szczegółowe informacje, porównaj konfiguracje za pomocą testu serwera SSL Labs

Dzisiaj (marzec 2018 r.) witryna encrypted.google.com jest wycofana, a od 30 kwietnia 2018 r. encrypted.google.com będzie przekierowywać na www.google.com.

Z punktu widzenia infrastruktury (serwery, certyfikaty, parametry TLS) nie ma już znaczących różnic. Mimo że żądania są obsługiwane przez te same serwery (patrz koniec tej odpowiedzi), nadal istnieją pewne różnice między tymi dwiema domenami:

• Zlokalizowane przekierowania domen
  encrypted.google.com nie przekierowuje do innych domen, podczas gdy google.com próbuje przekierować do domeny specyficznej dla kraju ( ccTLD).
  Aby uniknąć tego przekierowania, https://google.com/ncr jest często proponowany. Jednak działa to tylko wtedy, gdy włączone są pliki cookie. Aby zapobiec wykonywaniu przekierowań bez konieczności używania plików cookie, dołącz parametr gws_rd = cr do adresu URL.

  (w poniższych punktach nie będę już rozróżniać między www.google.com i ccTLD)

• Znakowanie marki w wyszukiwarce Google
  W przeciwieństwie do google.com interfejs użytkownika encrypted.google.com nie wyświetla linków do innych produktów / aplikacji Google. Na przykład. porównaj nagłówek w google.com (zarchiwizowany) z encrypted.google.com (zarchiwizowany). Dzieje się tak prawdopodobnie dlatego, że encrypted.google.com został wprowadzony specjalnie do zaszyfrowanego wyszukiwania (obecnie obsługa protokołu HTTPS jest dobrze ugruntowaną wartością domyślną; wówczas protokół https został wprowadzony jako funkcja opcjonalna).

• Wyciek strony odsyłającej i śledzenie użytkowników
  W obu przypadkach referer HTTP dla normalnych wyników wyszukiwania nie zawiera pierwotne wyszukiwane hasła w postaci zwykłego tekstu (chociaż istnieje wiele niejasnych parametrów adresu URL, które mogą potencjalnie służyć do śledzenia użytkownika, co jest jeszcze bardziej prawdopodobne, jeśli witryna korzysta z usług Google, takich jak Google Analytics).
  Ukrywanie tego słowa kluczowego jest często implementowane (w zależności od przeglądarki, urządzenia, funkcji przeglądarki, takich jak JavaScript), nie poprzez bezpośrednie linkowanie do miejsca docelowego, ale poprzez użycie pośredniego adresu URL jako wyniku wyszukiwania, np. [google domain] / url? q = [docelowy adres URL] (reklamy są kierowane przez wiele przekierowań i zawierają oryginalne wyszukiwane hasła, niezależnie od domeny Google).
  Czasami (znowu, w zależności w przeglądarce itp.) Google używa <meta content = "origin" name = "referrer" > w celu usunięcia elementu odsyłającego HTTP oraz alternatywnych metod śledzenia (np. beacony lub audyt hiperłączy).

  (W chwili pisania tego tekstu, encrypted.google.com używa tej pierwszej w Google Chrome, a www.google.com używa drugiej metody. Ale to naprawdę niewiele znaczy. Np. w Internet Explorerze 11 , ta pierwsza metoda jest używana dla obu domen Google.)

  Aby zachować pierwotny docelowy adres URL bez wycieku strony odsyłającej, można użyć rozszerzenia przeglądarki „Don't Track Me Google”: https: //github.com/Rob--W/dont-track-me-google

  (Nawet bez żadnej interwencji ze strony witryn takich jak Google można również wyczyścić element odsyłający HTTP. Na przykład , gdy inicjatorem jest HTTPS, a docelowym HTTP lub , gdy używany jest tryb przeglądania prywatnego przeglądarki Firefox, lub jeśli użytkownik używa flag lub rozszerzeń, które wyłączają / usuwają odnośnik ( przykład dla przeglądarki Chrome, przykłady dla przeglądarki Firefox)).

W przeszłości występowała również różnica w wycieku informacji przez stronę odsyłającą HTTP, ale jest to już nie jest. Porównaj strony pomocy dotyczące wyszukiwania SSL:

• Pomoc wyszukiwarki Google - wyszukiwanie SSL (dostęp: kwiecień 2013 r.) (wiele akapitów tekstu)
• Pomoc wyszukiwarki Google - wyszukiwanie SSL (najnowsze) (prawie brak tekstu)

Poniższy test pokazuje, że dwie różne domeny Google mogą być rozpoznawane na różne adresy IP i że te adresy IP są w stanie obsłużyć zapytania wyszukiwania dla dowolnej domeny wyszukiwania Google.

  $ host zaszyfrowany .google.comencrypted.google.com to alias dla www3.l.google.com.www3.l.google.com ma adres 172.217.20.78 www.3.l.google.com ma adres IPv6 2a00: 1450: 400e: 80a: : 200e $ host www.google.comwww.google.com ma adres 172.217.20.68 www.google.com ma adres IPv6 2a00: 1450: 400e: 800 :: 2004 $ curl -I https://encrypted.google.com/ --resolve encrypted.google.com:443:172.217.20.68$ curl -I https://encrypted.google.com/ --resolve encrypted.google.com:443:172.217.20.78$ curl -I https: // www.google.com/?gws_rd=cr --resolve www.google.com:443:172.217.20.68$ curl -I https://www.google.com/?gws_rd=cr --resolve www.google.com : 443: 172.217.20.78 $ curl -I https://www.google.nl/?gws_rd=cr --resolve www.google.nl:443:172.217.20.78

last curl polecenia all otrzymywać wyniki wyszukiwania bez dalszych przekierowań (nie uwzględniłem ich wyników w tej odpowiedzi). Aby zobaczyć szczegóły SSL, zamień -I na -vvv lub użyj czegoś takiego jak openssl s_client -connect google.com:443.

Zgodnie z pytaniem OP: „Jakie były korzyści z przeglądania zaszyfrowanej wyszukiwarki Google pod względem bezpieczeństwa?”

Nie ma różnicy.

Szczegóły: patrząc na nich dzisiaj, 16 stycznia 2017 r., jedyną różnicą jest to, że ta „zaszyfrowana” nie ma ikony Google Apps w prawym górnym rogu.

DNS www.google.com wskazuje 6 cyfr w przestrzeni 74.x, podczas gdy encrypted.google.com trafia tylko do jednej z 216 pozycji. W związku z tym wygląda na to, że www jest lepiej / lepiej zrównoważone pod względem obciążenia niż zaszyfrowane.

Oba używają tego samego certyfikatu, więc jeśli ktoś jest zaniepokojony wyciekiem klucza prywatnego między jednym a drugim, są takie same.

Czytając forum Google, encrypted.google.com został zaimplementowany w celu testowania i programowania i nie musi być używany. Ponieważ www.google.com jest teraz https, nie ma potrzeby korzystania z encrypted.google.com w zakresie bezpieczeństwa / szyfrowania.

Patrząc na odpowiedź „curl”, są one prawie identyczne i nie widzę żadnej różnicy funkcjonalnej.

Czy Google może mieć na końcu inny skrypt? Jasne, ale to nie zmieni odpowiedzi na pytanie PO.

Według Google w 2010 roku był to sposób na przechodzenie zaszyfrowanych wyszukiwań przez nazwaną subdomenę, tak aby organizacje, które chciały filtrować wyszukiwania (szkoły itp.), mogły nadal sprawdzać przeszukiwane wyszukiwania SSL i blokuj szyfrowane wyszukiwania, których nie mogli sprawdzić.