I often use a guest WiFi which does the usual intercept; attempt to navigate to any HTTP website and it redirects you to the "Agree to our ToS" page, after which it will permit any traffic from your MAC address in the normal way.

Usually I just pick any web page and hit reload, but this WiFi does not like https://. The query must be http://.

OK, so I go into the address bar and delete the "s" from HTTPS, and hit "go". E.G. http://www.amazon.com/usual-Amazon-URL-here

And then my local browser puts the "s" back. It makes the query on port 443, which the guest WiFi blocks. It has to be the local browser doing this, since it has literally no Internet. I can vouch for this occurring on Amazon's Silk browser, Firefox on Android, and I believe Safari/iOS.

Is this a policy of web browser clients to force to HTTPS anytime the browser knows the site supports HTTPS? What threat does that defend against?

  • That's weird. Firefox and Chrome do have a captive portal detection, which they try first.
    – Braiam
    May 12, 2018 at 10:02
  • @Braiam so does the device itself, but it's hit or miss. May 12, 2018 at 13:05
  • As well as HSTS, the browser will cache standard HTTP to HTTPS 301 redirects. (A "guest WiFi" that does not permit HTTPS connections!? That is limiting and a little scary!)
    – MrWhite
    May 13, 2018 at 20:05
  • 1
    @MrWhite The issue is that the guest WiFi needs you to go to their captive portal first, after which they will allow HTTPS. In order to do that, they redirect any connection to their captive portal until you log on through it, but naturally if it tries to redirect an HTTPS connection, the browser blocks it.
    – forest
    May 13, 2018 at 23:38
  • @forest "if it tries to redirect an HTTPS connection, the browser blocks it." - Ah, ok, thanks for the clarification.
    – MrWhite
    May 14, 2018 at 14:45

2 Answers 2


I suggest you look into NeverSSL, a simple site which will always be served over plain HTTP.

If you are sure it is your browser doing it and not a redirect on the server side, it is likely the result of a security feature called HTTP Strict Transport Security (HSTS). When a website wants to only serve over an encrypted connection, it sets an HTTP header that instructs the browser to only ever connect over TLS. Some sites may even use HSTS preloading, where the redirection policy is hardcoded into the browsers by default, rather than being set via an HTTP header over the network. HSTS of all kinds is designed to defeat MITM attacks that exploit the fact that your browser would be perfectly happy to stay on the non-encrypted version of a site, even if HTTPS is available. According to Security Headers, Amazon uses HSTS. This explains why you are being redirected.

  • 3
    Good to know that website exists. I've always used example.com, but no guarantees that'll work forever I guess. May 12, 2018 at 4:43
  • @multithr3at3d example.com is probably one of the safer choices, actually. That said, having alternatives rarely hurts.
    – user
    May 13, 2018 at 16:13
  • @MichaelKjörling But example.com supports HTTPS. It could start using HSTS just to make a point, or the browser may be using HTTPS Everywhere which may redirect it.
    – forest
    May 13, 2018 at 23:39

In some browsers you can verify using debugger tools that the browser is rewriting http:// to https:// because of HSTS. For example, in Google Chrome:

  1. hit F12 to open debugger tools and go to the Network tab
  2. go to http://www.amazon.com/ in the address bar
  3. the Network tab will quickly fill up with a list of all the URLs being requested; scroll to the top

The first request will be for http://www.amazon.com/ . When I select that request, in the right-hand box I see these lines (among others):

Request URL: http://www.amazon.com/  
Status Code: 307 Internal Redirect  
Location: https://www.amazon.com/  
Non-Authoritative-Reason: HSTS

Not the answer you're looking for? Browse other questions tagged .