Is it there any difference between the encrypted Google search (at https://encrypted.google.com) and the ordinary HTTPS Google search (at https://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.
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.
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
google.com just redirect to www.google.com? How do you even use the former without using the latter?
Commented
Jan 17, 2017 at 18:37
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=cr parameter 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:
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.
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.
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.
referermakes 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.