Re: An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs through HTTP header)

On Wed, Feb 04, 2015 at 11:20:40AM +0100, Mike West wrote:
>
> This is exactly what HSTS is for, isn't it? I'm not a huge fan of creating
> yet another pinning mechanism.

A fair point, but....
 
> Splitting into "Insecure", "Pretty Secure For Newer Clients", and "Always
> Secure Forever And Ever And Don't Let Anyone Touch It" seems like a
> division folks can wrap their heads around. Adding more flags complicates
> the model significantly.

I think I'm persuaded that (even with better sys admin tools in
the pipeline) we should avoid complicated configuration options which
exacerbate the problems developers have but obscure-but-vital aspects of TLS.

So I like your trichotomy of states, and agree with trying to design
around it.

Unfortunately, I think that does mean that both HSTS and the proposed new
CSP upgrade flag should have the overlapping effect of upgrading
navigational HTTP requests to the domains that set them.

If you're really unhappy about that overlap in functionality, WDYT about
implementing the exact same "Pretty Secure For New Clients" state as a
"Helpful" or "Easy" directive to the HSTS header, rather than a new CSP
directive?

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

Received on Wednesday, 4 February 2015 23:14:42 UTC