Wandering Thoughts archives

2010-11-01

Redirecting from HTTP to HTTPS is a bad security idea

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.

web/HttpToHttpsRedirectionBad written at 22:13:31; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.