Secondo Google, la differenza sta nel gestire le informazioni sui referrer quando si fa clic su un annuncio.

Dopo una nota di AviD e con con l'aiuto di Xander abbiamo condotto alcuni test ed ecco i risultati

1. Facendo clic su un annuncio:

• https://google.com : Google ti porterà a una pagina di reindirizzamento HTTP dove aggiungerebbero la tua query di ricerca alle informazioni del referrer.

• https://encrypted.google.com : se l'inserzionista utilizza HTTP, Google non comunicherà all'inserzionista la tua query. Se l'inserzionista utilizza HTTPS, riceverà normalmente le informazioni sul referrer (inclusa la query di ricerca).

2. Facendo clic su un normale risultato di ricerca:

• https://google.com : se il sito web utilizza HTTP, Google ti porterà a una pagina di reindirizzamento HTTP e non aggiungerà la query di ricerca alle informazioni del referrer. Diranno solo al sito web che vieni da Google. Se utilizza HTTPS, riceverà normalmente le informazioni sul referrer.

• https://encrypted.google.com : se il sito web su cui fai clic nei risultati utilizza HTTP, non avrà idea di dove ti trovi " proviene da o qual è la tua query di ricerca. Se utilizza HTTPS, riceverà normalmente le informazioni sui referrer.

Lo stesso argomento è stato trattato in un post del blog EFF.

MODIFICA : Google ha eliminato encrypted.google.com il 30 aprile 2018. Secondo Google, questo dominio è stato utilizzato per offrire agli utenti un modo per eseguire ricerche in sicurezza la rete. Ora tutti i prodotti Google e la maggior parte dei browser più recenti, come Chrome, utilizzano automaticamente le connessioni HTTPS.

Al momento della scrittura (luglio 2013), i due siti hanno preferenze diverse per gli algoritmi di scambio delle chiavi. Per ispezionare in Chrome, fai clic sull'icona del lucchetto e seleziona la scheda "connessione".

Contro Chrome 28, vanilla google.com utilizza ECDHE_RSA, encrypted.google.com utilizza ECDHE_ECDSA. Entrambi gli algoritmi danno la massima segretezza. https://www.imperialviolet.org/2011/11/22/forwardsecret.html

Per i dettagli, confronta le configurazioni utilizzando il test del server SSL Labs

Oggi (marzo 2018), encrypted.google.com è obsoleto e, dal 30 aprile 2018, encrypted.google.com reindirizzerà a www.google.com.

Dal punto di vista dell'infrastruttura (server, certificati, parametri TLS) non ci sono più differenze significative. Sebbene le richieste siano gestite dagli stessi server (vedi la fine di questa risposta), ci sono ancora alcune differenze tra i due domini:

• Reindirizzamenti di dominio localizzati
  encrypted.google.com non reindirizza ad altri domini, mentre google.com tenta di reindirizzare a un dominio specifico del Paese ( ccTLD).
  Per evitare questo reindirizzamento, https://google.com/ncr viene spesso proposto. Tuttavia, funziona solo se i cookie sono abilitati. Per evitare che il reindirizzamento avvenga senza richiedere i cookie, aggiungi il parametro gws_rd = cr all'URL.

  (per i punti seguenti, non distinguerò più tra www.google.com e ccTLD)

• Branding di Ricerca Google
  A differenza di google.com, l'interfaccia utente di encrypted.google.com non mostra collegamenti ad altri prodotti / app Google. Per esempio. confronta l'intestazione su google.com (archiviato) con encrypted.google.com (archiviato). Ciò è probabilmente dovuto al fatto che encrypted.google.com è stato introdotto specificamente per la ricerca crittografata (al giorno d'oggi, il supporto https è un'impostazione predefinita ben consolidata; all'epoca https veniva introdotto come funzionalità opzionale).

• Perdita dal referrer e tracciamento degli utenti
  In entrambi i casi, il referer HTTP per i normali risultati di ricerca non contiene i termini di ricerca originali in chiaro (sebbene ci siano molti parametri URL oscuri che possono essere potenzialmente utilizzati per tracciare l'utente, il che è ancora più probabile se il sito utilizza servizi Google come Google Analytics).
  Questa parola chiave che nasconde è spesso (a seconda del browser, del dispositivo, delle funzionalità del browser come JavaScript) implementata non collegandosi direttamente alla destinazione finale, ma utilizzando un URL di reindirizzamento intermedio come risultato della ricerca, ad es. [dominio google] / url? q = [URL di destinazione] (gli annunci vengono indirizzati attraverso più URL di reindirizzamento e includono i termini di ricerca originali, indipendentemente dal dominio Google).
  A volte (di nuovo, a seconda sul browser, ecc.) Google utilizza <meta content = "origin" name = "referrer" > per rimuovere il referer HTTP e metodi alternativi per il monitoraggio (ad es. beacon o controllo dei collegamenti ipertestuali).

  (Al momento della scrittura, encrypted.google.com utilizza il primo in Google Chrome e www.google.com utilizza il secondo metodo. Ma questo in realtà non significa molto. Ad esempio in Internet Explorer 11 , il primo metodo viene utilizzato per entrambi i domini Google.

  Per mantenere l'URL di destinazione originale senza perdere il referrer, è possibile utilizzare l'estensione del browser "Don't Track Me Google": https: //github.com/Rob--W/dont-track-me-google

  (Anche senza alcun intervento da siti web come Google, è possibile pulire anche il referer HTTP. Ad esempio , quando il mittente è HTTPS e la destinazione HTTP, o quando viene utilizzata la modalità di navigazione privata di Firefox, o se l'utente utilizza flag o estensioni che disabilitano / rimuovono il referer ( esempio per Chrome, esempi per Firefox)).

In passato c'era anche una differenza nella fuga di informazioni tramite HTTP Referer, ma questo è non è più così. Confronta le pagine della guida per la ricerca SSL:

• Guida di Google Search - Ricerca SSL (recuperata ad aprile 2013) (molti paragrafi di testo)
• Guida di Ricerca Google - Ricerca SSL (ultima) (quasi nessun testo)

Il seguente test mostra che i due diversi domini di Google possono risolversi in diversi indirizzi IP e che questi indirizzi IP sono in grado di gestire le query di ricerca per qualsiasi dominio di ricerca di Google.

  $ host encrypted .google.comencrypted.google.com è un alias per www3.l.google.com.www3.l.google.com ha indirizzo 172.217.20.78 www.3.l.google.com ha indirizzo IPv6 2a00: 1450: 400e: 80a: : 200e $ host www.google.comwww.google.com ha indirizzo 172.217.20.68 www.google.com ha indirizzo 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

l'ultimo curl comanda tutti ricevere i risultati della ricerca senza ulteriori reindirizzamenti (non ho incluso il loro output in questa risposta). Per visualizzare i dettagli SSL, sostituire -I con -vvv o utilizzare qualcosa come openssl s_client -connect google.com:443.

Secondo la domanda dell'OP, "In termini di sicurezza, quali sono stati i vantaggi di navigare attraverso la ricerca crittografata di Google?"

Non c'è differenza.

Dettagli: esaminandoli entrambi oggi, 16 gennaio 2017, l'unica differenza che vedo è che quello "crittografato" non ha l'icona di Google Apps in alto a destra.

Il DNS per www.google.com punta a 6 voci nello spazio 74.x, mentre encrypted.google.com va a solo uno nello spazio 216. Pertanto, sembra che www sia più / meglio bilanciato del carico rispetto a quello crittografato.

Entrambi usano lo stesso certificato, quindi se qualcuno è preoccupato per una perdita di chiave privata per uno o per l'altro, è lo stesso.

Leggendo il forum di Google, encrypted.google.com è stato implementato per i test e lo sviluppo e non è necessario utilizzarlo. Poiché www.google.com ora è https, non è più necessario utilizzare encrypted.google.com per quanto riguarda la sicurezza / crittografia.

Guardando la risposta di "curl" sono quasi identici e non vedo alcuna differenza funzionale.

Google potrebbe avere uno script diverso da parte loro? Certo, ma questo non cambierebbe la risposta alla domanda OP.

Secondo Google nel 2010, era un mezzo per le ricerche crittografate passare attraverso un sottodominio denominato in modo che le organizzazioni che volevano filtrare le ricerche (scuole, ecc.) potessero ancora ispezionare le ricerche in corso SSL e blocca le ricerche crittografate che non hanno potuto ispezionare.