I'll address the DoS thing momentarily but first I'm curious if there's any data out there on how widely deployed HSTS currently is and/or to what extent site/domain owners are committing to support it going forward? Also are the cases where self-DoS might occur well known? The cases I can think of generally fall into 3 different categories, but since the actual ways in which you might shoot yourself in the foot are numerous (and subtle) I'd argue that choosing to implement HSTS is a much larger commitment than HTTPS alone. For one thing, you need knowledge of your whole domain and the content being delivered (and how it's being deployed) or you run the risk of screwing something up. You hit upon one such case below, where a subdomain that doesn't have SSL becomes inaccessible due to the "includeSubdomains" flag. Actually the other case is a problem too, but for illustration purposes I'll talk about the former. So, consider a brand like Nike who has a large internet presence and a lot of products serving different people and markets. I don't personally know anything about them or how they get their internet needs met, but let's just assume for this discussion they have a bunch of different teams and outsourcing agreements that try to make it all work (something I think could be said for all major corporations). Next, let's suppose they want to run a marketing campaign during a major sports event and give away free shoes to the first 500 people who sign up at a new micro site setup just for this campaign. The browser requests go something like this (substituting - for. ) 1. Go to the landing page at freeshoes-nike-com using http 2. Grab some some logo graphics from nike-com using https, hsts is enabled with includesubdomains 3. Grab a js file at freeshoes-nike-com that will collect people's information using http, which is rewritten to be https but a cert was never installed for "freeshoes" Clearly you are screwed, the page will not display correctly. And if you try to go back to the landing page (with just http), you're even worse off because then nothing shows up, only the error screen. People will be very upset, especially the marketing team who can do nothing but watch their campaign blow up before their very eyes. Put simply, a debacle such as this would be a very big deal, and no matter how much people might like the idea of security there is not a person out there who wants to risk losing their job just to be more secure. So that's why I have a hard time seeing HSTS becoming widely adopted. Maybe it will make my site more secure but if it's going to screw everything up, I'm not interested. Bait-and-switch. Some of the other DoS cases might be even more problematic, but I don't know if anyone wants to get into them here. Thanks.
On 09/23/2014 10:03 PM, fhw...@gmail.com wrote: ...snip... > The shortcoming of HSTS is on the deployment side, where on the one hand > it purports to help web app developers and deployment teams who falter > at security and on the other hand gives those same people all-new ways > to falter at security. It's your classic bait-and-switch except this > time your site could become unusable. ...snip... A site can only DOS itself if it sets a long-lived header and then stops supporting https (or if it sets includeSubdomains and a subdomain doesn't support https). The easy answer is if your site is committed to always supporting https, then HSTS is appropriate. If not, then it isn't appropriate. > The most ambitious of web sites and services will be up for the > challenge of doing a proper HSTS implementation but the rest...I don't > know. Any thoughts on how widely this will be adopted? Again, using HSTS is essentially as difficult as using https properly. If that's doable (and it's definitely a whole lot easier than it used to be), then setting an HSTS header is a small incremental step that does increase a site's security. | ||
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
