What is the difference between https://google.com and https://encrypted.google.com?
According to Google, the difference is with handling referrer information when clicking on an ad.
After a note from AviD and with the help of Xander we conducted some tests and here are the results
1. Clicking on an ad:
https://google.com: Google will take you to an HTTP redirection page where they'd append your search query to the referrer information.https://encrypted.google.com: If the advertiser uses HTTP, Google will not let the advertiser know about your query. If the advertiser uses HTTPS, they will receive the referrer information normally (including your search query).
2. Clicking on a normal search result:
https://google.com: If the website uses HTTP, Google will take you to an HTTP redirection page and will not append your search query to the referrer information. They'll only tell the website that you're coming from Google. If it uses HTTPS, it will receive referrer information normally.https://encrypted.google.com: If the website you click in the results uses HTTP, it will have no idea where you're coming from or what your search query is. If it uses HTTPS, it will receive referrer information normally.
The same topic was covered in an EFF blog post.
EDIT: Google dropped encrypted.google.com as of April 30 2018. According to Google, this domain was used to give users a way to securely search the internet. Now, all Google products and most newer browsers, like Chrome, automatically use HTTPS connections.
At the time of writing (July 2013), the two sites have different preferences for key exchange algorithms. To inspect in Chrome, click the padlock icon and select the 'connection' tab.
Against Chrome 28, vanilla google.com uses ECDHE_RSA, encrypted.google.com uses ECDHE_ECDSA. Both algorithms give forward secrecy. https://www.imperialviolet.org/2011/11/22/forwardsecret.html
For details, compare the configurations using the SSL Labs server test
- https://www.ssllabs.com/ssltest/analyze.html?d=encrypted.google.com
- https://www.ssllabs.com/ssltest/analyze.html?d=google.com
- https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com
Today (March 2018), encrypted.google.com is deprecated, and as of 30 April 2018, encrypted.google.com will redirect to www.google.com.
From the infrastructure point of view (servers, certificates, TLS parameters), there are no significant differences any more. Although the requests are handled by the same servers (see the end of this answer), there are still some differences between the two domains:
Localized domain redirects
encrypted.google.com does not redirect to other domains, whereas google.com attempts to redirect to a country-specific domain (ccTLD).
To avoid this redirect, https://google.com/ncr is often proposed. However, that only works if cookies are enabled. To prevent the redirection from happening without requiring cookies, append thegws_rd=crparameter to the URL.(for the points below, I won't differentiate between www.google.com and ccTLDs any more)
Google Search branding
Unlike google.com, encrypted.google.com's UI does not show links to other Google products/apps. E.g. compare the header at google.com (archived) with encrypted.google.com (archived). This is likely because encrypted.google.com was introduced specifically for encrypted search (these days, https support is a well-established default; back then https was introduced as an optional feature).Referrer leakage and user tracking
In both cases, the HTTP referer for normal search results does not contain the original search terms in clear text (though there are many obscure URL parameters that can potentially be used to track the user, which is even more likely if the site uses Google services such as Google Analytics).
This keyword hiding is often (depending on the browser, device, browser features as JavaScript) implemented by not directly linking to the final destination, but by using an intermediate redirection URL as the search result, e.g.[google domain]/url?q=[destination URL](advertisements are routed through multiple redirection URLs and include the original search terms, regardless of the Google domain).
Sometimes (again, depending on the browser, etc.) Google uses<meta content="origin" name="referrer">to strip the HTTP referer, and alternative methods for tracking (e.g. beacons or hyperlink auditing).(At the time of writing, encrypted.google.com uses the former in Google Chrome, and www.google.com uses the latter method. But this does really not mean much. E.g. in Internet Explorer 11, the former method is used for both Google domains.)
To keep the original destination URL without leaking the referrer, my "Don't Track Me Google" browser extension can be used: https://github.com/Rob--W/dont-track-me-google
(Even without any intervention from websites such as Google, the HTTP referer can also be cleaned. For example, when the originator is HTTPS and the destination HTTP, or when Firefox's private browsing mode is used, or if the user is using flags or extensions that disable/strip the referer (example for Chrome, examples for Firefox)).
In the past there was also a difference in information leakage through HTTP Referer, but that is not the case any more. Compare the help pages for SSL Search:
- Google Search Help - SSL Search (retrieved April 2013) (many paragraphs of text)
- Google Search Help - SSL Search (latest) (almost no text)
The following test shows that the two different Google domains may resolve to different IP addresses, and that these IP addresses are able to handle search queries for any Google search domain.
$ 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
The last curl commands all receive the search results without further redirects (I haven't included their output in this answer). To see the SSL details, either replace -I with -vvv or use something like openssl s_client -connect google.com:443.