Chris's Wiki :: blog/web/HttpToHttpsRedirectionBad

Redirecting from HTTP to HTTPS is a bad security idea

November 1, 2010

Every so often, people setting up SSL websites have the bright idea that to be friendly, they should have a non-SSL version of the site that redirects people to the SSL website. They are entirely correct that this is the friendliest approach, but you shouldn't do it if you care about security.

(There are plenty of reasons to use SSL even if you don't care about security. Pervasive SSL frustrates all of the people who want to stick their fingers in traffic between actual users and your website, starting with the user's ISP (with various sorts of stupid proxy tricks) and moving on to less allegedly friendly sorts.)

If you care about security, it is deadly for anything that should be SSL-encrypted to be accidentally transmitted in the clear. One of the ways that you avoid both accidents and users developing bad habits is to make them not work; that way, users are conditioned not to do that and if your website ever makes a URL-generation mistake you will notice right away because it doesn't work at all.

To put it another way: if the encryption matters, non-SSL URLs can't be interchangeable with SSL URLs because one isn't encrypted and the other is. If they are interchangeable, you are taking the thing that you said was important and making it unimportant.

The worst sort of HTTP to HTTPS redirection is when you do URL-based redirection, so a page on the HTTP site is redirected to the same page on the HTTPS site; this enables the most user bad habits and hides the most mistakes. It is especially bad if this works for things like your login form, where you are transmitting the most sensitive data. Next worst is redirection from any URL on the HTTP site to the root of your HTTPS site. If you have to have an HTTP site at all, my opinion is that it should just be a plain page without any links on it that tells people to use your HTTPS site.

(If you have a HTTP site at all, consider setting up log monitoring for what URLs turn up and having alarms go off if any sensitive URLs show up.)

Sidebar: why you don't want any links on your HTTP site

It's very friendly for attackers if you train users that they can go to your HTTP site (by just typing the name into their URL bar) and then click on a link on the page to go to your secure website. We already know that users are terrible at actually looking at where they are going, so if an attacker can interpose their own version of your unprotected web page they can send your users to any secure web server they want to and most users will be none the wiser.

Sidebar: my view on ISP meddling in web traffic

Yes, I will admit that some ISPs sometimes have excellent reasons to want to transparently impose things like caching proxies between their users and outside websites. But it's a little bit like the email world; your intentions may be good, but unfortunately a lot of other people have already poisoned that particular well. There is too much of a history of various sorts of bad and evil ISP meddling for me to take that chance any more, and so I am willing to block the attempts of the rare good caching ISP in order to frustrate all the other ISPs out there.

This is only going to become more acute if various governments get their way about requiring ISPs to keep more and more records of people's Internet traffic. If that happens, I will also hope very hard that TLS SNI actually becomes usable.

Comments on this page:

From 89.27.51.67 at 2010-11-02 09:23:12:

How would redirection lead to content that should be SSL-encrypted to be accidentally transmitted in the clear? If http://example.com/(.*) simply redirects the user agent to https://example.com/\1 with HTTP 301, surely the only thing potentially exposed are request headers of the HTTP request? Is this what you meant?

By Dan.Astoorian at 2010-11-02 10:23:46:

@89.27.51.67: If the HTTP request is a POST, the entire form is exposed.

(I've been stung by an even worse configuration: where the server itself doesn't even bother to redirect the http:// URL, but processes http:// and https:// identically and relies on the links within the site to funnel the user to the secure version of the pages. This isn't necessarily a complete catastrophe, until a test version of the application that contains the insecure URLs--e.g., because it was developed before certificates were purchased to nail down the secure ones--sneaks into production.)

I can't agree with Chris's conclusions, though. Users will be users, and not providing an easy path from your http:// site to your https:// one does nothing to mitigate hijacking the http:// URLs by an interposer, and not redirecting visitors to the correct page will confuse more users than it will successfully train. No user will ever type your web server's hostname and then realize "if this were the real site, it would have told me to type in the https:// URL instead of presenting what looks like a valid login form." Hoping that the inconvenience of not being automatically redirected to the right site will discourage users from typing naked hostnames into the URL bar in the future is unrealistic: it's the online equivalent of giving a random electric shock to a lab rat. The users just aren't going to understand the distinction well enough to change their behaviour.

If you redirect the http:// URL to the https:// login page, at least you've got a pretty good chance that the user will bookmark the right page for next time.

--Dan

By cks at 2010-11-02 10:32:06:

There are any number of sensitive things that can be visible in HTTP requests, even if you are careful to make all of your cookies be secure, HTTPS-only cookies. POSTs are the obvious case, but often query parameters and even URLs can leak potentially sensitive information such as user IDs, user names, modules that you have access to or that exist on the web server, and so on.

I disagree with Dan, unsurprisingly. I think that I can put it this way: if you don't have a HTTP site at all, having a migration path from it to your HTTPS site is irrelevant.

From 195.26.247.141 at 2010-11-02 11:12:03:

I think that I can put it this way: if you don't have a HTTP site at all, having a migration path from it to your HTTPS site is irrelevant.

Especially since a vanishingly small number of people will hit the https site directly, for all the reasons given above.

I agree with the sentiment of "http bad, https good", but having no redirect or no http site at all is just asking for your site to have zero visitors, I'm afraid.

By cks at 2010-11-08 11:26:29:

[Belated reply department:]

I've got two views here. First, I think a decreasing amount of people come to websites by typing their hostname in the URL bar of browsers. Far more people either use Google searches (even for hostnames) or come through explicit links from other web pages, and either case makes http versus https irrelevant.

Second, if this is a serious worry I would suggest putting the security sensitive portion of your websites on a different hostname (or several, to separate various different bits). People can then still come to your main corporate website or the like by typing in the URL bar, but at least all of your secure activity is more protected.

Written on 01 November 2010.

«	How I run two Firefoxes at once and still have remote control

One reason that I call us a midsized environment