HSTS Privacy Vs Security

Yesterday I launched HSTSCookie.ca as a reference implementation for Firefox 7's handling of HSTS. I'm not the first to think of using HSTS as a state machine, but I had not seen any other actual implementations to proove the theory in the wild.

So check out hstscookie.ca... It's a partial implementation and I chose only to pick on Firefox because they handle expiring HSTS info a little differently than Chrome does. In Chrome, deleting cookies will delete the HSTS information, in Firefox you have to delete 'site preferences' item. I chose not to put it on a real wildcard cert, mostly because I wanted there to be a real opt-in to try it out, but also because the cheapest wildcard cert I could find was $200 -- which is rediculus for something that costs nothing to create and only validates domain ownership.

So what does it mean for HSTS... well. It means that privacy interested users will see limited benefits from this technology. If you're like me and delete pretty much everything the browser tracks when closing the browser, then HSTS just wont add any security. The pins and sts state will disappear at shut down. On the other hand if you want the security of HSTS, you have to accept a persistent cookie policy and the tracking/privacy downsides that come with that.

In my opinion, HSTS is broken at the design level and can't be fixed in its current form. Instead, STS and Certificate Pinning should be handled in the DNS through a TXT or SRV record setup. Don't require the user's browser remember whether the site should be HSTS.