Re: Upgrade mixed content URLs through HTTP header

On Mon, Feb 02, 2015 at 04:47:38PM +0100, Mike West wrote:
> On Mon, Feb 2, 2015 at 4:39 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 
> > Equivalent, but not identical. My proposal would be to upgrade in
> > Fetch similar to HSTS so that any scripts are not affected by URLs
> > changing.
> >
> 
> Hrm. So the result would be the same as a redirect? The document would have
> an insecure URL, but we'd end up making a secure request?
> 
> I don't think this is a terrible idea, and it avoids some of the concerns
> Adam and Ryan (CC'd. Hi Adam and Ryan!) raised in the past regarding HSTS's
> request-order-dependent behavior.
> 
> That said, I'm not sure it actually solves W3C's concern, as it would leave
> legacy clients out in the cold. The only way to support clients that don't
> support the thing we haven't implemented yet would be to alter the links at
> the source. I totally understand that that's difficult, but it seems
> essential.

It seems like you're saying that a security mechanism can't be allowed
to help new clients upgrade to HTTPS if it doesn't also help old ones?

That's an extreme position; wouldn't it make more sense to say that the
mechanism shouldn't break or downgrade the experience that old clients
were getting?  And that old clients should then join the fold through
security patches?

If you really meant that new clients can't have a safe experience unless
old ones do, then we'd be stuck using serverside proxies to parse and
upgrade rewrite HTML and JS on the fly, which is a terrible design.

The normal situation is that security features get deployed in new
clients and then spread from there; why is this case different?

-- 
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:31:24 UTC