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.

  • 4
    There's no top navigation bar in encrypted. – John Isaiah Carmona Mar 11 '13 at 9:35
  • 2
    @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. – Konrad Rudolph Mar 11 '13 at 10:51
  • 8
    @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. – Konrad Rudolph Jul 2 '13 at 20:55
  • 2
    @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 ;) – Luc Jul 2 '13 at 21:02
  • 2
    @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. – curiousguy Sep 20 '13 at 17:22
up vote 202 down vote accepted

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.

  • 40
    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. – Smith John Jul 2 '13 at 18:05
  • 7
    @EvanTeitelman The link becomes a redirect when I click on it. – curiousguy Sep 20 '13 at 18:13
  • @Adnan, So this is all? I mean, they built encrypted.google.com just to do that referrer thing? – Pacerier Jun 9 '14 at 22:01
  • @EvanTeitelman, No it doesn't work, try it. – Pacerier Jun 9 '14 at 22:05
  • 7
    @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. – Adi Jun 10 '14 at 7:01

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

  1. https://www.ssllabs.com/ssltest/analyze.html?d=encrypted.google.com
  2. https://www.ssllabs.com/ssltest/analyze.html?d=google.com
  3. https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com
  • 3
    This answer is no longer correct. Now both use ECDHE_ECDSA. See, e.g., ssllabs.com/ssltest/…. – D.W. Jun 16 '16 at 23:12
  • 2
    @D.W.: You sure? I still see ECDHE_RSA on www.google.com. – Mehrdad Jan 17 '17 at 8:01
  • @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. Jan 17 '17 at 16:58
  • 2
    @D.W.: Doesn't google.com just redirect to www.google.com? How do you even use the former without using the latter? – Mehrdad Jan 17 '17 at 18:37
  • @Colonel, So after Google shut down encrypted.google.com, did they really "incorporate" the strong SSL functionality into google main page? – Pacerier May 23 at 18:32

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.

  • Wow, you did this research all by yourself? – Pacerier May 23 at 18:33
  • @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. – Rob W May 24 at 10:44

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.

  • Did you look at referer headers? What about encryption algrorithms? – noɥʇʎԀʎzɐɹƆ Jan 17 '17 at 3:38
  • @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. – MikeP Jan 17 '17 at 19:52
  • can you list what you checked? There isn't much of a body here. – noɥʇʎԀʎzɐɹƆ Jan 17 '17 at 19:53

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.

  • 1
    Notice how the current bounty reason is "current answers are outdated". – noɥʇʎԀʎzɐɹƆ Jan 21 '17 at 19:19
  • 1
    Yep. I got that. But if the reasons haven't changed .... – schroeder Jan 21 '17 at 21:35
  • 2
    provide evidence they haven't then – noɥʇʎԀʎzɐɹƆ Jan 21 '17 at 21:36
  • 1
    This answer describes the design intent for the difference (the ability to block encrypted searches). The other answers tested the functional difference. The design intent remains unchanged. It's a historical fact at this point. – schroeder Jan 21 '17 at 21:38

protected by Community Nov 11 '14 at 11:14

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.