It started on Twitter:

@thatcks: All things considered I've decided it's time my personal website went not just https-available but all-https (with redirects from http).

@zaitcev: wait a moment, didn't you write on your blog how evil it was to redirect http?

Pete Zaitcev is quite correct; I wrote about the issue back in this entry, yet here I am redirecting everything from HTTP to HTTPS myself. There are two answers here. I'll start with the long, rambling one.

The simple answer is that I'm not doing this for security. There's almost nothing 'secure' on my personal website and right now the only person who can do anything security related on it is me (and I can move myself to https directly). I'm doing this for privacy because I feel like making a point, however pointless it is on the grander scale of things.

Of course it would still be a good idea to not redirect from HTTP if you really care about privacy; every HTTP request that gets redirected tells what is now an entirely non-hypothetical eavesdropper the URL that your visitor was requesting and often things like referers. But this is where we run into pragmatic issues, namely backwards compatibility: there are a certain amount of HTTP URLs for my site out there and I would like to not break them. Certainly not right away and probably not ever (because cool URLs don't go away).

Security (in the broad sense) is always about tradeoffs. The most secure, most privacy-enhancing option today would be to move my personal website to being a Tor hidden service with no automatic redirection, but as a side effect this would reduce my traffic to essentially nil. The most clearly usable option would be to continue using HTTP and never mind any (quixotic) privacy concerns on behalf of my few visitors. Somewhere in the middle is the right balance between security (in the form of privacy) and real usability by the visitors that I care about. This balance may be different for every situation and thus for every website.

(Part of what makes it different is what will be revealed about your visitors by this sort of initial traffic analysis. Revealing that they go to your login form is a lot different than revealing that they are trying to look up potentially sensitive things.)

Now it's time for the short one: once people have made a HTTP request it's too late for full security. It doesn't matter what reply your web server gives for the request because a non-hypothetical eavesdropper has already seen the requested URL and other associated data (including at least some of the POST body if any). If they care enough they can reverse engineer what your visitor was trying to visit even if your web server denies the URL's (HTTP) existence; this is especially the case if your web server is willing to confirm that the HTTPS version of the URL actually exists.

In short, the real purpose of refusing to redirect HTTP requests is to force people to stop making them in the first place. It adds no real security until (and unless) people do this.

(It follows that the really secure approach is to shut off your HTTP site entirely; don't even have a web server responding on port 80. If people can't connect they can't send a HTTP request to be snooped on.)

Once people have blown a certain amount of privacy by making that initial HTTP request, how your web server responds is partly a pragmatic question of how effective not redirecting them is going to be in getting rid of those inbound HTTP requests versus how usable you want to be.

In my case my guess is that almost all inbound requests will shift to HTTPS soon even if I do a friendly HTTP to HTTPS redirection and the remaining amount of inbound requests will basically never shift. The requests that will shift come from search engine lookups, links in my syndication feeds being followed, and new links that I and other people tweet, link to, and so on. The requests that won't shift are from the existing links on Twitter, in other people's blog entries, and so on. Even if I broke those links they would be unlikely to go away and to stop generating inbound requests. So on the whole I might as well redirect them; the privacy leak has already happened by the time that my webserver can do anything (assuming I keep a HTTP site at all).