2

I'm on a coffee shop wifi. I just typed https://google.com in to my browser and noticed that I got redirected to http://google.com. I tried other google domains (google.ie) and these work fine, so presumably they're black listing certain domains.

What are the likely techniques for the owner of this wifi to achieve this?

Andy Smith
  • 2,762
  • 1
  • 19
  • 24
  • 2
    Have you tried https://encrypted.google.com ? See [What is the difference between https://google.com and https://encrypted.google.com?](http://security.stackexchange.com/questions/32367/what-is-the-difference-between-https-google-com-and-https-encrypted-google-c) – CodesInChaos Sep 28 '13 at 11:23
  • 1
    Google has lots of weird redirections going on when you use `google.com`. For example a redirect to your countries local google version. Perhaps one of those redirects is acting stupidly in your case. – CodesInChaos Sep 28 '13 at 11:26
  • @CodesInChaos After posting this actually went from happening every time to becoming an intermittent issue. I was just using google normally (type search in to chrome bar) and google themselves showed a little box notifying me that I wasn't using SSL - I looked and I wasn't. But now I'm thinking this may be a different issue. – Andy Smith Sep 28 '13 at 11:33
  • what browser where you using? IE doesn't support HSTS. – rook Sep 28 '13 at 16:44
  • @Rock I was using Chrome – Andy Smith Sep 28 '13 at 17:14
  • @rook If I understand this right, you would not need HSTS to be protected from e.g. SSL-strip if you enter `https://` into the URL-bar, as OP says he did. – Anders Dec 01 '16 at 12:03
  • 1
    @Anders your right, `nosslsearch.google.com` what a blunder. It looks like that domain is no longer active. – rook Dec 04 '16 at 16:14

3 Answers3

5

This is actually a feature that Google support. If the person in control of the DNS servers for the network changes the CNAME for "www.google.com" to point to "nosslsearch.google.com" then Google will disable SSL for requests.

This is known as the NoSSLSearch option, more details are here: https://support.google.com/websearch/answer/186669?hl=en

Andy Smith
  • 2,762
  • 1
  • 19
  • 24
  • 1
    And we thought Google had got over its collusion with censors (or PR spun it away). Oh they sing a merry jig and call it "for schools" (as if teenagers should be left uneducated) but the feature clearly isn't limited to a subset of eager censors. – LateralFractal Oct 16 '13 at 10:04
1

If this is a MiTM attack from the owner or someone on the WiFi network then the browser will not give a warning to the user as suggested by some of the comments. Your browser has no knowledge that a site should be using Transport Layers Security (TLS/SSL) so how would it know to warn you. If the attacker is trying to inject their own certificate then yes you will get a warning but if you're having the TLS stripped out and being redirected to http:// then you would not. However, due to the implementation of HSTS I don't believe someone could maliciously redirect you away from a secure redirect to Google this way. It's also worth noting that if you manually navigate to https://google.com and don't just type google.com (where the browser would default to http://) then it's not possible for someone to MiTM the secure connection.

There is a program called SSLstrip that would allow you to carry out these forms of MiTM attack on a redirect to a https:// site which you can find here. There is a slightly more detailed explanation of how SSLstrip handles the MiTM attack.

Scott Helme
  • 3,198
  • 3
  • 22
  • 32
  • The strange this is that I was typing `https://google.com` in to the browser and it was occurring. However - I can't say for sure that that's what I did first, so maybe chrome had cached the redirect? – Andy Smith Sep 28 '13 at 19:27
  • 1
    This sounds like perhaps a problem on Google's end. If you type chrome://net-internals/#hsts in your Chrome address bar at the bottom you can query hosts that Chrome recognises as HSTS Hosts. Whilst google.com doesn't issue a HSTS Policy it is a preloaded HSTS Host in the Chrome browser. – Scott Helme Sep 28 '13 at 19:36
  • @ScottHelme, HSTS still fails if the initial connection to the site was done with http which could allow an attacker to keep the user from connecting the secure version of the site and do evil things to them. – AdnanG Sep 29 '13 at 04:17
  • @AdnanG The whole point of HSTS is to prevent exactly that from happening. HSTS completely mitigates attacks such as those using SSLstrip. The user agent (browser) will not allow a connection to a HSTS host via HTTP. The only one opportunity an attacker has is the very first time the user connects to the site before they have knowledge of the HSTS policy. Once the browser has seen the HSTS policy it will transform any insecure URI reference *before* dereferencing them. http://tools.ietf.org/html/rfc6797#section-2.2 – Scott Helme Sep 30 '13 at 06:50
0

If this is being done by the owner of the WiFi network, he must be using an intercepting proxy that redirects all traffic from https to http and able to do MITM attack on the traffic. you should try accessing the site of gmail as the authentication page should not be directed to http. if it is, then there is definitely MITM going on.

AdnanG
  • 707
  • 2
  • 8
  • 18
  • How would that work? Do you have an example of software that does this? – Andy Smith Sep 28 '13 at 10:54
  • 1
    That shouldn't be possible without a sternly worded browser warning – CodesInChaos Sep 28 '13 at 11:22
  • @CodesInChaos Exactly, that's what I was thinking. I'm now unsure, because my https connections are *occasionally* going through. So perhaps it's not the network being sneaky but some issue with my browser/google/something else – Andy Smith Sep 28 '13 at 11:32
  • You will get a warning if you intercept the https with your own certificate. However, just a redirection will not give you any warning. Have a look at the proxies mentioned in this list: http://thewasps.blogspot.com/2008/02/tools.html – AdnanG Sep 28 '13 at 12:11