Quelle est la différence entre https://google.com et https://encrypted.google.com?
Y a-t-il une différence entre la recherche Google cryptée (à https://encrypted.google.com ) et la recherche Google HTTPS ordinaire (à https://google.com =)?
En termes de sécurité, quels sont les avantages de la navigation via la recherche Google cryptée?
Notez que ce n'est pas une question sur [~ # ~] http [~ # ~] vs [~ # ~] https [~ # ~] . Ce sont deux services Google.
Selon Google , la différence réside dans la gestion informations sur le référent lorsque vous cliquez sur une annonce.
Après une note d'AviD et avec l'aide de Xander nous avons effectué quelques tests et voici les résultats
1. Cliquer sur une annonce:
https://google.com: Google vous amènera à un HTTP page de redirection où ils ajouteraient votre requête de recherche aux informations du référent.https://encrypted.google.com: Si l'annonceur utilise HTTP, Google ne l'informera pas de votre requête. Si l'annonceur utilise HTTPS, il recevra normalement les informations du référent (y compris votre requête de recherche).
2. Cliquer sur un résultat de recherche normal:
https://google.com: Si le site Web utilise HTTP, Google vous amènera à un HTTP page de redirection et n'ajoutera pas votre requête de recherche aux informations du référent. Ils diront uniquement au site Web que vous venez de Google. S'il utilise HTTPS, il recevra normalement les informations de référence.https://encrypted.google.com: Si le site Web sur lequel vous cliquez dans les résultats utilise HTTP, il n'aura aucune idée d'où vous venez ni quelle est votre requête de recherche. S'il utilise HTTPS, il recevra normalement les informations de référence.
Le même sujet a été couvert dans un billet de blog EFF .
[~ # ~] modifier [~ # ~] : Google a supprimé encrypted.google.com au 30 avril 2018. Selon Google , ce domaine a été utilisé pour donner aux utilisateurs un moyen de rechercher en toute sécurité sur Internet. Désormais, tous les produits Google et les navigateurs les plus récents, comme Chrome, utilisent automatiquement les connexions HTTPS.
Au moment de la rédaction (juillet 2013), les deux sites ont des préférences différentes pour les algorithmes d'échange de clés. Pour inspecter dans Chrome, cliquez sur l'icône de cadenas et sélectionnez l'onglet "connexion".
Contre Chrome 28, Vanilla google.com utilise ECDHE_RSA, encrypted.google.com utilise ECDHE_ECDSA. Les deux algorithmes confèrent le secret. https://www.imperialviolet.org/2011/ 11/22/forwardsecret.html
Pour plus de détails, comparez les configurations à l'aide du test du serveur SSL Labs
Aujourd'hui (mars 2018), encrypted.google.com est obsolète , et au 30 avril 2018, encrypted.google.com redirigera vers www.google.com.
Du point de vue de l'infrastructure (serveurs, certificats, paramètres TLS), il n'y a plus de différences significatives. Bien que les demandes soient gérées par les mêmes serveurs (voir la fin de cette réponse), il existe encore quelques différences entre les deux domaines:
Redirection de domaine localisé
encrypted.google.com ne redirige pas vers d'autres domaines, tandis que google.com tente de rediriger vers un domaine spécifique au pays ( ccTLD ).
Pour éviter cette redirection, https://google.com/ncr est souvent proposé. Cependant, cela ne fonctionne que si les cookies sont activés. Pour empêcher la redirection de se produire sans nécessiter de cookies, ajoutez legws_rd=crparamètre à l'URL.(pour les points ci-dessous, je ne ferai plus de différence entre www.google.com et les ccTLD)
Marque Google Search
Contrairement à google.com, l'interface utilisateur de encrypted.google.com n'affiche pas de liens vers d'autres produits/applications Google. Par exemple. comparer l'en-tête sur google.com (archivé) avec encrypted.google.com (archivé) . Cela est probablement dû au fait que encrypted.google.com a été introduit spécifiquement pour la recherche cryptée (de nos jours, la prise en charge de https est une valeur par défaut bien établie; à l'époque, https a été introduit comme fonctionnalité facultative).Fuite des référents et suivi des utilisateurs
Dans les deux cas, le référent HTTP pour les résultats de recherche normaux ne contient pas les termes de recherche d'origine en texte clair (bien qu'il existe de nombreux paramètres d'URL obscurs qui peuvent potentiellement être utilisés pour suivre l'utilisateur , ce qui est encore plus probable si le site utilise des services Google tels que Google Analytics).
Ce masquage de mots clés est souvent (en fonction du navigateur, de l'appareil, des fonctionnalités du navigateur comme JavaScript) implémenté en ne liant pas directement à la destination finale, mais en utilisant une URL de redirection intermédiaire comme résultat de la recherche, par exemple[google domain]/url?q=[destination URL](les publicités sont acheminées via plusieurs URL de redirection et incluent les termes de recherche d'origine, quel que soit le domaine Google).
Parfois (encore une fois, selon le navigateur, etc.) Google utilise<meta content="Origin" name="referrer">pour supprimer le référent HTTP et d'autres méthodes de suivi (par exemple vérification des balises ou des hyperliens ).(Au moment de la rédaction du présent document, encrypted.google.com utilise l'ancien dans Google Chrome et www.google.com utilise la dernière méthode. Mais cela ne signifie pas grand-chose. Par exemple, dans Internet Explorer 11, l'ancienne méthode est utilisée pour les deux domaines Google.)
Pour conserver l'URL de destination d'origine sans divulguer le référent, mon extension de navigateur "Don't Track Me Google" peut être utilisée: https://github.com/Rob--W/dont-track-me-google
(Même sans aucune intervention de sites Web tels que Google, le référent HTTP peut également être nettoyé. Par exemple, lorsque l'expéditeur est HTTPS et le HTTP de destination, ou lorsque le mode de navigation privée de Firefox est utilisé , ou si l'utilisateur utilise des indicateurs ou des extensions qui désactivent/suppriment le référent ( exemple pour Chrome , exemples pour Firefox )).
Dans le passé, il y avait également une différence de fuite d'informations via HTTP Referer, mais ce n'est plus le cas. Comparez les pages d'aide pour la recherche SSL:
- Aide Google Search - Recherche SSL (récupéré en avril 2013) (plusieurs paragraphes de texte)
- Aide Google Search - Recherche SSL (dernière) (presque pas de texte)
Le test suivant montre que les deux domaines Google différents peuvent se résoudre en adresses IP différentes et que ces adresses IP sont capables de gérer les requêtes de recherche pour n'importe quel domaine de recherche Google.
$ Host encrypted.google.com
encrypted.google.com is an alias for www3.l.google.com.
www3.l.google.com has address 172.217.20.78
www3.l.google.com has IPv6 address 2a00:1450:400e:80a::200e
$ Host www.google.com
www.google.com has address 172.217.20.68
www.google.com has IPv6 address 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
Les dernières commandes curl reçoivent toutes les résultats de la recherche sans autres redirections (je n'ai pas inclus leur sortie dans cette réponse). Pour voir les détails SSL, remplacez -I avec -vvv ou utilisez quelque chose comme openssl s_client -connect google.com:443.
Selon la question du PO, "En termes de sécurité, quels étaient les avantages de la navigation dans la recherche Google cryptée?"
Il n'y a pas de différence.
Détails: En les regardant tous les deux aujourd'hui, 16 janvier 2017, la seule différence que je vois, c'est que celui `` crypté '' n'a pas l'icône Google Apps en haut à droite.
Le DNS de www.google.com pointe vers 6 entrées dans l'espace 74.x, tandis que encrypted.google.com ne passe qu'à un seul dans l'espace 216. Ainsi, il semble que www soit plus/mieux équilibré en charge que crypté.
Ils utilisent tous les deux le même certificat, donc si quelqu'un s'inquiète d'une fuite de clé privée pour l'un contre l'autre, ils sont les mêmes.
En lisant Google forum , encrypted.google.com a été implémenté pour les tests et le développement, et n'a pas besoin d'être utilisé. Étant donné que www.google.com est désormais https, il n'est pas nécessaire d'utiliser encrypted.google.com en matière de sécurité/cryptage.
En regardant la réponse de "curl", ils sont presque identiques, et je ne vois aucune différence fonctionnelle.
Google pourrait-il avoir un script différent de son côté? Bien sûr, mais cela ne changerait pas la réponse à la question OP.
Selon Google en 201 , c'était un moyen pour les recherches cryptées de passer par un sous-domaine nommé afin que les organisations qui voulaient filtrer les recherches (écoles, etc.) puissent toujours inspecter les recherches passant par SSL et bloquer recherches cryptées qu'ils n'ont pas pu inspecter.