RE: STS and "mixed content" (Part 3 of Re: Feedback on the Strict-Transport-Security specification)

> -----Original Message-----
> From: public-web-security-request@w3.org [mailto:public-web-security-
> request@w3.org] On Behalf Of Adam Barth
> Sent: Thursday, December 17, 2009 10:46 PM
> To: =JeffH
> Cc: W3C Web Security Interest Group; Eric Lawrence
> Subject: Re: STS and "mixed content" (Part 3 of Re: Feedback on the
> Strict-Transport-Security specification)
> 
> 
> Recommendation: If we want to block mixed content with STS, we should
> block *active* content.  This strikes a balance between the security
> benefits of banishing mixed content and the deployability benefits of
> letting sites implement the features they need.  (I'd probably define
> active content as everything except iframes, images, video, and
> audio.)
> 
> Thoughts?

Adam,

I'm inclined to think that STS itself shouldn't be an adjustment to how browsers currently handle "mixed content" as I really view the scope of the STS header to be just the "origin" it came from, and not applying to anything else. 

This is a view that I echoed when EV certificates came out and most browser vendors showed visual "EV Indicators" such as a green-location-bar when the primary site had an EV certificate, regardless of whether it included content/images/etc. from non-EV sites.  

I envision STS working the same way. If we want to start specifying how browsers should handle mixed content, I think that belongs in another policy.  

The intent of STS really being to cache SSL preference.  Any site that is currently all-SSL as is mostly required for STS already has a problem with mixed-content.  STS isn't an attempt to solve that, it is an attempt to solve/change the HTTP-First behavior of web browsers when presented with an unqualified domain, or a MITM attack.

Or so I claim :)

--
Andy Steingruebl
 

Received on Monday, 28 December 2009 22:12:14 UTC