Posted by: Eric Hansen
There’s a new RFC that was published this month (http://tools.ietf.org/html/rfc6797) about an additional layer of HTTPS for web browsing, called HSTS (HTTP Strict Transport Security). The basic idea behind it is that the server tells the browser that only HTTPS is allowed, or where to find the secure version of the website, while browsers that don’t support this feature will browse the insecure version.
Now there’s really no comparison I can find behind this and just simply using a rewrite rule in your favorite web server to force HTTPS, but it’s still an interesting take. It seems like an additional handshake for a service that actually does nothing more than force security on a user. The use cases (http://tools.ietf.org/html/rfc6797#section-2.1) further exemplify this fact.
From their thread model, it handles passive and active network attackers, as well as imperfect web developers. However, it does not fix phishing and malware issues. One has to wonder then what the point of HSTS is? It basically does everything HTTPS but perhaps over HTTP (which, then, would nullify security completely and be a broken chain…)
I know RFCs are not intended to be super-awesome-de-facto things, and some are even jokes (the coffee pot protocol comes to mind), but this is just like saying “hey, I wrote a web server by compiling Apache’s code!” I’m just not following it, and while it has some interesting points of use (using the UA string and HTTP response headers), I’m not sold on this as being a viable security solution. All it sounds like, especially by the last threat model use, is a lazy man’s ways of forcing HTTPS on users.