When requesting a website, let's say "crypto.stackexchange.com" often you get redirected to a secure connection, in this case "https://crypto.stackexchange.com". Would I then request an insecure connection (http), get redirected to the secure https protocol by the http response, and thus making a less secure request?

  • Yes. This prevents adversaries from hijacking HTTP traffic and stripping out the redirects to HTTPs. Take a look at sslstrip. – cypherfox Mar 15 '18 at 13:07

Would I then request an insecure connection (http), get redirected to the secure https protocol by the http response, and thus making a less secure request?

It depends.
In all generality the answer is yes, you are making an insecure HTTP request first and then the server tells you (hopefully with a 301 response) that you should use the HTTPS site instead and the browser loads that one. Of course, on the first insecure request anything could happen, including you being served a fake website. However there are (at least) three exceptions to this rule, which will make the browser look up the HTTPS version directly. So let's go through them!

  • 301 Redirect Caching. 301 is the HTTP status code for "permanently moved" and some browsers are caching this response and don't even try to request the old site anymore but send you straight to the new one, for performance reasons and in this case a HTTP to HTTPS redirect would also profit from this.
  • Browser Add-Ons. There are browser add-ons which keep a database of domains supporting HTTPS (somewhat) and if you request data from any of these domains, the add-on will automatically re-write the request to ask for the HTTPS version of the site. HTTPS Everywhere famously does this and covers a wide range of websites which don't deem their HTTPS "production-ready" (such as Stackexchange prior to March 2017).
  • HTTP Strict Transport Security (HSTS). This is flag in the HTTP response header which states that the site (and optionally all its sub-domains) may only be accessed using HTTPS during the next specified days without exception. This way, when you request a known HSTS domain, the browser will directly convert the HTTP request to a HTTPS request automatically. As a bonus, you can register for HSTS pre-loading for your site with the browser vendors and then the browsers will come with your HSTS entry pre-equipped starting with the next update. Stackexchange has HSTS deployed without pre-loading (on most sites).

Yes, It's better to explicitly specify https from the beginning.

While 'proper' webmasters implement things like 301/302 redirects and HSTS. Not everybody does this. I recently did a scan of Malaysian Government Websites, and found that a significant number of sites don't redirect you from http to https -- even though the https site exist.

This means, that clients calling the http site, only get the http site, even though a more secure option exist. The client has to explicitly call https if it wants the secure version.

Other sites use javascript to redirect users from http to https, which can fail if you've blocked scripts like me.

By specifying https from the get-go, you'll request the secure site first, saving you time (no more redirects) and ensuring you always get the secure page.

Sadly, the reason browsers don't make this the default behavior is that not every site has https -- but every site with https is expected to have a http (if only just to redirect), so everything defaults to http first, and hopefully a redirect happens.

As a last note, if the site has HSTS. The Browser will automatically redirect itself (307 redirect) for the max-age that HSTS is set to, in which case the browser defaults to https until the max-age expires.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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