Problem number 4 is actually also relevant for HTTPS-only websites. That is, if the website doesn't use HSTS, and most don't.

Also a 301 only works for one page. Consider this: You go to example.com (typed in address bar), it redirects you to https://example.com via a 301, then you load your favorite news website, I inject an iframe in the news website that loads http://example.com/pwnd, and the browser happily sends the cookie (if it wasn't set to secure-only).

The HSTS header is what you need to do, not only a 301.

You're right, but I was thinking along the lines of: The reason why they don't set secure cookies is probably because they want to share state between their HTTP site and their HTTPS site.

> Also a 301 only works for one page.

You can make it work on every page. Even the query string will remain intact. POST requests are more complicated, but they are usually triggered by forms and JS on your own pages, so you have more control over that.

    RewriteEngine on
    RewriteCond %{HTTPS} !on
    Rewrite (.*) https://www.example.com/$1 [L]

AWS does this for (almost) free - load balancing includes optional SSL termination. really simple to set up, all HTTPS traffic just forwards to port 80 on your instance.

If a visitor goes to http://domain/some/url they should not redirect to https://domain/some/url - it makes it harder to catch pages that use the wrong protocol.

Better to redirect http://domain/some/url to https://domain

Edit: if you're logging referrers from your own domain with non https:// urls AND using secure cookies, ignore my comment!

Why not just do the redirect that you know is right, but log it (with referer, so you know what needs fixed)?

For example, let's suppose you have a secure page that's referencing some JavaScript resource via a plain-text connection. Because of the redirection, the browser will ultimately fetch the required file, but only trying plain-text HTTP first. That one plain-text request can be hijacked by a man-in-the-middle attacker and abused to take over the victim's browser (and account).

Further, if your users have bookmarks to plain-text pages, their first access to your web site is always going to be insecure, which means that they can be attacked via sslstrip.

These problems are solved with Strict Transport Security, but it will probably take some time until we can fully rely on it.

In the meantime, the plain-text URL can be preserved, and the redirection carried out via an intermediary page that explains why links to plain-text pages are dangerous. It's ugly, but I don't think there's a better (safer) way.

If a user's browser ever sends a port 80 request, you've already lost (assuming the MITM is there). On your end you may even never see a plaintext request. But in all other instances, displaying an intermediary page is a chance to educate your users, and possibly get them to change their bookmarks.

Further, with little work you may be forcing the MITM to do some custom coding (a lot of work) in order to make the attack seamless.

I wouldn't do this for just any web site, but if you're running a bank or something similarly sensitive, it would probably be worth it.

Not really. Although old browsers don't support HSTS, they still respect the "secure" flag in cookies. So if an old browser ever requests an insecure resource, no cookies are sent with it, so the bad guys can MITM your connection all day long and no harm will be done. You only need to make sure that your own web pages never request resources over HTTP, and this is relatively easy to do.

> On your end you may even never see a plaintext request.

If so, there's no point doing fancy redirects anyway. How do you redirect a request that you never see? Therefore this scenario isn't really worth losing sleep over.

> displaying an intermediary page is a chance to educate your users, and possibly get them to change their bookmarks.

Users don't want to be educated, period.

Also, technically when a browser encounters a 301 redirect, it should update the relevant bookmark automatically. In reality no browser does this, but that's what the standards say anyway.

Not true. Once a MITM hijacks the victim's communication with the server, she can do whatever she wants, including stripping the "secure" flag from session cookies. She may not be able to compromise a previous secure cookie, but she can hijack a brand new session, wait for the user to authenticate, and gain access that way. The communication from the victim to the MITM will be plain-text with insecure session cookies; the communication from the MITM to the server can be SSL with secure cookies.

And if we're talking just about an insecure resource (not a page, but, for example, a JavaScript file), the MITM can simply inject malicious code into it and hijack the browser that way.