Actually, isn't it bad to redirect http to https?

Question

I have a two-part question about question #570288 over on ServerFault.

Question:

Is it bad to redirect http to https?

Accepted answer (185 up-votes):

[...] Hell no. It's very good.

Part 1

Is that answer, well... wrong? :)

Am I correct that, from a security point of view, redirecting HTTP to HTTPS is a terrible idea for your users, who might know very little about security?

As I understand it, HTTP conversations can be MODIFIED and your client will have no way of knowing.

If the bad guy intercepts your HTTP 302 redirect and replaces it with a redirect to evil.com, (even evil.com via HTTPS), the client will be completely unaware.

This is why security professionals have always recommended that you bookmark the HTTPS version of a site, or type https into the address bar, right? (Does HSTS mitigate this? Does HTTPSEverywhere mitigate this?)

Part 2

Is this important enough that we should do what we can to get that answer updated?

• Right now that question is being featured in the "Hot Network Questions" sidebar on StackExchange network sites.
• There's one mention MITM, in a comment buried in the middle of the page.

Answer 1

Redirecting from HTTP to HTTPS is not a bad thing. What is bad is relying on it as if it was a security feature.

This redirection is a lighthouse, meant to allow ships lost at sea in the storm to understood where they are and, with luck, give them a better chance to reach a safe haven. Nobody claims that lighthouses make storm disappear; they just improve probabilities of a happy ending for bad conditions.

The only bad thing that can be said about an automatic redirect from HTTP to HTTPS is that it breeds complacency. If a user errs, e.g. by trying to access the Web site as HTTP instead of HTTPS, the automatic redirect allows him to persist in his mistaken ways, hiding the fact that his inappropriate URL exposed him to the vindictiveness of Internet dwellers, some being quite proactively evil at times. Disabling this redirection could be construed as being more pedagogical. However, this point of view is somewhat unrealistic; most Web site owners are in no position to educate users. What they want is to grab the attention of potential customers. If you begin to make access to your Web site more difficult, then they will just go away; they will not be educated in the slightest way, and business will suffer.

"That which does not kill us makes us stronger." A catchy phrase from a more-than-half mad philosopher; but not necessarily applicable to the general public as an educational policy. The problem with making people stronger by trying to kill them is that sometimes you succeed -- to kill them, I mean.

As mr spuratic explains, to really makes things better, browser should use HTTPS by default; ideally, the whole Web would be HTTPS-only: if browsers try HTTPS first but fall back to HTTP in case of errors, then an active attacker can simulate the failure and force a fallback. DNSSEC coupled with appropriate SRV records could advertise, in a secure way, that a given server should be used with HTTPS only, but this will work reliably only when... it will work everywhere (same bootstrap problem as IPv6).

In the mean time, a redirect will bring stray sheep to the stable even when the sheep are completely unaware of the wild beasts who roam the night-time countryside. This is usually considered a more efficient method than trying to teach sheep not to stray.

Answer 2

The problem is twofold:

• Today, there is no way for a website (or other service) to definitively state (e.g. via authenticated DNS) that it only provides a HTTPS (secure) service, never HTTP. Service records (_srv) don't do the job (though the problem was not ignored entirely, see the https entry here), and HSTS has an unavoidable problem. The initial redirection from HTTP to HTTPS is a necessary evil today. HTTPS Everywhere (try HTTPS first) is a technically a better fix, though any solution which requires user opt-in and/or a non-trivial degree of user-competence is critically limited. sslstrip will persist until this is addressed. (DNSSEC has a similar bootstrapping problem, and will do until 99% of domains are signed, and 100% of resolvers expect that. DNS is often the elephant in the room.)
• As well as the problem of (effectively) unauthenticated redirection, unconditional transparent redirection to HTTPS may hide potential problems (e.g. application generation of absolute URLs with the wrong protocol:// prefix when a HTTPS terminating load-balancer/reverse-proxy is in use). Cookie security attributes like "secure" are band-aid. The facilities for keeping a HTTPS session strictly HTTPS are imperfect.

By way of a thought experiment: imagine if an SSH client helpfully and silently, tried telnet first. What if an SSH connection could near-silently turn into telnet connection half-way through? How popular would this client be amongst the security conscious? If it always "just worked" (and had plugins/themes etc.), how popular would it be amongst the security agnostic? How is this different^† to a contemporary browser?

_{^† Aside from the improbable memory requirements, gratuitous UI inconsistencies, and incessant background updates; these should go without saying.}

Is it bad to redirect http to https?

HTTPS is good, but relying on the redirection to happen via an unauthenticated, unencrypted and unverifiable transport indicates a degree of optimism usually associated with the customers of national lotteries.

redirecting HTTP to HTTPS is a terrible idea[...]?

Not completely true. A user who always observes the HTTPS UI indicators has reasonable cause to believe he's in the right place, and has certain protections. I suspect this is not the modal user however.

What is bad is an administrator naïvely concluding that enabling HTTPS somehow solves all common security problems.

That pesky triad of authentication, integrity, confidentially really is all or nothing...

TL;DR: it's not a terrible idea, it almost certainly doesn't solve the problems one might hope it does, but there are no viable alternatives that solve them either. Simply foisting this on your users will probably only have an impact on an insignificant fraction of them; running a campaign and educating your users will get you much further.