Re: Upgrade mixed content URLs through HTTP header

On Tue, Feb 03, 2015 at 10:25:08AM +0100, Eduardo' Vela" <Nava> wrote:
> It would be helpful to upgrade sites even if they aren't HSTS already.
> On Feb 3, 2015 10:21 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
> 
> > On Tue, Feb 3, 2015 at 10:18 AM, Eduardo' Vela" <Nava> <evn@google.com>
> > wrote:
> > > Would this enable the upgrade only? Without the STSing?
> > >
> > > Strict-Transport-Security: max-age=0; upgradeSubresources
> >
> > I think Mike was suggesting not to extend HSTS but instead use the
> > presence of HSTS as a signal to upgrade all mixed content URLs within
> > the document. It's not entirely clear to me if that is compatible with
> > what is out there today. And if coupling it with HSTS helps adoption
> > or makes it harder.

Reasons for including it in HSTS: 

 - It should only be set over HTTPS
 - It should have a time-to-live, like HSTS
 - It overlaps significantly in functionality and implementation with HSTS 
 - A preload list for it is nice

Reasons for not wanting to tie it to HSTS:

 - maybe you don't want all the other trappings of strictness:
   - don't punish cert expiry so severely
   - allow cert warning clickthroughs
   - allow user-controlled mixed content loads if the subresource
     upgrades fail

Possible solution: when adding "upgradeSubresources" or "helpful" mode,
also allow the site operator to turn off those kinds of strictness,
something like:

Strict-Transport-Security: max-age=0; upgradeSubresources allowCertWarning allowMCBdisable allowRecentExpiry

Or maybe just one directive for all of that stuff at once.

-- 
Peter Eckersley                            pde@eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

Received on Tuesday, 3 February 2015 09:47:56 UTC