What is the difference between https://google.com and https://encrypted.google.com?
In terms of security what were the benefits of browsing through encrypted Google search?
Note that this is not a question about HTTP vs HTTPS. These are two Google services.
@John Whoa. I’ve made this my default search engine now. I don’t care about referrers (I’ve disabled them anyway) but the missing top bar is a killer feature.
@KonradRudolph The http referer header is one of the most useful things for webmasters. If you come from a https website it's not sent anyway, so no data is leaked. You may consider enabling it again for our sake.
@Luc It may be useful but it’s also a crass invasion of the user’s privacy. A website generally has no business knowing how I get there. I agree that it’s *useful* for the website to know but only in rare instances does the *user* profit from that.
@KonradRudolph As an example, yesterday I looked at the referring sites from a website I maintain and found some things I hadn't expected people to search for. Knowing those (one example search was "harbor roermond", in Dutch) we can optimize the website so that we can be found more easily; we weren't the top hit while some above us were useless linkspam. I myself never did it, but even if this was only to make money, then even in that case the user might profit from it. But this could become a very long discussion. Feel free to ping me in the DMZ or another room if you want to discuss it ;)
@KonradRudolph User profit is possible, indirectly: the `referer` makes it possible to log the origin of external links (from Y to X); sometimes these links generate a 404 error in X; if the webmaster of X cares enough, he could get in touch with the webmaster of Y so that links could get fixed. From the amount of broken links I see, I conclude that this is very rarely done. The best way to deal with broken links is obviously to avoid them in the first place, with stable URLs.
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.
One benefit of this: copying a link from a Google search result will give you a link to a webpage, not the jumbled mess of a redirect link.
@Adnan, So this is all? I mean, they built encrypted.google.com just to do that referrer thing?
@Pacerier Originally, no. The `encrypted.` domain was where Google first rolled SSL support. However, after they added SSL support to the main domain, that became the distinction.
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
This answer is no longer correct. Now both use ECDHE_ECDSA. See, e.g., https://www.ssllabs.com/ssltest/analyze.html?d=google.com&;s=126.96.36.199.
@Mehrdad, www.google.com is different from google.com and encrypted.google.com, and ends up with different ciphersuites. This answer is talking about google.com vs encrypted.google.com. Look at the handshake simulation for the latest version of Chrome. We get: google.com => ECDHE_ECDSA, encrypted.google.com => ECDHE_ECDSA, www.google.com => ECDHE_RSA.
@D.W.: Doesn't `google.com` just redirect to `www.google.com`? How do you even use the former without using the latter?
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 the
gws_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).
[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 188.8.131.52 www3.l.google.com has IPv6 address 2a00:1450:400e:80a::200e $ host www.google.com www.google.com has address 184.108.40.206 www.google.com has IPv6 address 2a00:1450:400e:800::2004 $ curl -I https://encrypted.google.com/ --resolve encrypted.google.com:443:220.127.116.11 $ curl -I https://encrypted.google.com/ --resolve encrypted.google.com:443:18.104.22.168 $ curl -I https://www.google.com/?gws_rd=cr --resolve www.google.com:443:22.214.171.124 $ curl -I https://www.google.com/?gws_rd=cr --resolve www.google.com:443:126.96.36.199 $ curl -I https://www.google.nl/?gws_rd=cr --resolve www.google.nl:443:188.8.131.52
curlcommands all receive the search results without further redirects (I haven't included their output in this answer). To see the SSL details, either replace
-vvvor use something like
openssl s_client -connect google.com:443.
@Pacerier Yes. I was looking for a way to search without redirects after the deprecation of encrypted.google.com, and looked up its history and technical details. I already knew about referrer leakage due to my previous work on Don't Track Me Google, and all together I basically have an up-to-date answer to this question, so I decided to post it.
Per the OP question, "In terms of security what were the benefits of browsing through encrypted Google search?"
There is no difference.
Details: Looking at them both today, Jan 16, 2017, the only difference that I see is that the 'encrypted' one does not have the Google Apps icon on the top right.
The DNS for www.google.com points to 6 entires in the 74.x space, whereas encrypted.google.com goes to only one in the 216 space. Thus, it looks like www is more/better load balanced than encrypted.
They both use the same certificate, so if someone is concerned about a private key leakage for one vs. the other, they are the same.
Reading the Google forum, encrypted.google.com was implemented for testing and development, and doesn't need to be used. Since www.google.com is now https, there is zero need to use encrypted.google.com regarding security/encryption.
Looking at the response from "curl" they are nearly identical, and I don't see any functional difference.
Could Google have a different script on their end? Sure, but that wouldn't change the answer to the OP question.
@noɥʇʎԀʎzɐɹƆ, My referer is either origin or is blank. Encryption algorithms are not relevant in my opinion, as they have a tendency to change often and without notice.
According to Google in 2010, it was a means for encrypted searches to go through a named subdomain so that those orgs that wanted to filter searches (schools, etc.) could still inspect searches going through SSL and block encrypted searches that they could not inspect.