Yes, these are real problems, but how is redirecting to the home page helping in any way? When the user navigates back to the page she wanted the in-secure script will still be fetched. A MITM is still able to serve a copy of your page.
I wasn't arguing for redirecting to the home page, only to avoid redirecting (to the intended destination on port 443) automatically.
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.
If a user's browser ever sends a port 80 request, you've already lost (assuming the MITM is there).
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.
> 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.
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.
