Why is Chrome forcing SSL when I try to hit my domain?

2

1

I've got a bit of a weird problem and a stack of symptoms that I can't make sense of.

I have a .com domain that points to my home IP address. Inside my LAN, I use external DNS resolution, so if I perform an nslookup internally, I get my external IP rather than the LAN IP.

Here's what happens:

  • When I am at home (on a device that has an internal IP, say 10.0.0.20)
  • AND I am running Chrome for Windows (running Chrome 35 atm)
  • AND I try to reach a resource using my external domain name via HTTP (e.g. http://www.homedomain.com)

... then Chrome immediately converts the protocol to https (in the address bar) and complains about an SSL error. I can't reach the target.

It works as expected if I use the same Chrome build on an external machine (e.g. same user profile on my PC at the office). It also works locally using Internet Explorer and Firefox. It is only an issue running Chrome internally. I can reproduce this on 2 different machines, one running Windows 8.1 and the other Windows 7, and can reproduce it both on wifi and wired.

My home server runs Windows Server Essentials 2012 and I have an internal domain, but I don't think the server is involved in my issue.

I've configured my router to forward port 1880 to a Raspberry Pi device, where I have an http server listening. Outside of Chrome, I can hit http://www.homedomain.com:1880 and it will resolve perfectly. When I try it in Chrome, it instantly converts to https and fails (because the RPi isn't accepting SSL connections). When I use the LAN IP in Chrome it also works.

The router is running the Tomato firmware.

What's going on here?

  • It can't be a blatant Chrome setting/bug, because the same Chrome profile/version works when I am outside the LAN.
  • It can't be a local PC setting, because IE and Firefox work fine.
  • It can't be my Windows Server, because the router itself is handling the port forwarding.
  • It can't be the router, because IE and Firefox work fine.

I'm out of ideas - clearly one of my above assumptions is incorrect. Does Chrome have fancier network code that is causing unexpected behaviour in my situation? Can I have some kind of loopback issue that IE/FF are gracefully handling?

I've run out of ideas. If anyone has a suggestion for where to investigate I'd appreciate it.

Update: Another piece of data - Chrome (using the same user profile) behaves correctly when run inside a Hyper-V VM hosted on an affected machine.

Update 2: This behaviour goes away when I create a new Chrome user profile. The moment I log that profile into my Google account, however, the problem returns. It seems to be "something in the Chrome user profile" that is tied to my Google account.

Stefan Mohr

Posted 2014-06-06T18:37:40.080

Reputation: 439

dunno and this may be irrelevant but does it make a difference whether you are logged in to google or not? I find if I go to www.google.com it goes https if i am logged in. I also have an issue with a win xp sp2 machine running chrome, that when it tries to go to twitter it goes to https and gives en error. other browsers are fine – barlop – 2014-06-06T19:50:49.533

Good suggestion, @barlop! Being signed into Google or not (I used Incognito mode to test) didn't make a difference, but in checking that I discovered that this problem doesn't affect Chrome when it's run in a Hyper-V VM hosted on an affected computer. – Stefan Mohr – 2014-06-06T20:34:29.057

ah I just tested without being logged in (whether normal window or incognito window) and it went to https google.com About a year ago it only went to https when logged in. – barlop – 2014-06-06T20:43:58.610

Answers

4

Not a certainty by any means, but here's a guess:

Google Chrome (along with other modern browsers) supports the Strict-Transport-Security HTTP Header, which informs the browser that "this site is supposed to be accessed only via HTTPS, so in the future even if the user asks for HTTP give them HTTPS instead." As using HTTPS becomes more and more common, sending this header is becoming the default in new software and frameworks, as generally if HTTPS is set up at all (which it needs to be for the Strict-Transport-Security header to have any effect), it is preferable to use it for everything. Your experience leads me to think that at some point you tried to go to some page in Chrome on your domain over HTTPS, and that the application you used sent that header. So, Chrome on the affected machines has it in its Strict-Transport-Security list, so it won't allow going to non-HTTPS pages on that domain.

You don't mention ever trying to do anything on that domain ever via HTTPS, but is there a chance that you did at some point and that's when your trouble started? (The even less likely scenario is that your domain is on Chrome's compiled-in-preloaded HSTS list without you knowing.) I haven't found a way to view Chrome's Strict-Transport-Security list, so I don't know how to validate that it's the problem, but all "Chrome wants to go HTTPS and I don't know why" problems that I've seen ended up being that at some point the domain was over HTTPS and used the Strict-Transport-Security header, so that's the hypothesis I would assume for now, unless there's something else that can trigger the behavior in Chrome.

Hope that helps.

user169501

Posted 2014-06-06T18:37:40.080

Reputation:

3

Good thinking! I found in http://stackoverflow.com/a/10632901/106639 that you can access the Chrome HSTS list by navigating to about:net-internals and changing the dropdown list to HSTS. Looks like my domain isn't in the list, but that looks similar to what's happening.

– Stefan Mohr – 2015-06-10T19:51:54.333

Alright, well, Chrome didn't show my domain in the HSTS list when I searched, but I tried explicitly deleting it in the Delete box anyway and my problem has gone away! This might just be a quirk in the dev tools. Ugh! Thank you! – Stefan Mohr – 2015-06-10T19:58:44.407

Asked: 2014-06-06T18:37:40.080

Viewed: 3 780 times

Active: 2015-06-10T19:54:33.177