[HTTPS-Everywhere] [Technologists] what percentage of https everywhere rules are "simple" upgrades?

[Peter Eckersley]

On Mon, Jan 05, 2015 at 02:58:26PM -0500, Daniel Kahn Gillmor wrote:
> On 01/05/2015 01:52 PM, Peter Eckersley wrote:
> > We should definitely wade into this thread; I'm strongly of the view
> > that MCB is making HTTPS harder, and browsers should make the
> > opportunistic attempts even if they occasionally cause issues.  I might
> > be missing some horrible security flaw, but I can't think of it right
> > now.
> 
> There seem to be three options being discussed when the browser is
> directed to fetch an http resource from an https page:
> 
>  A) (status quo, roughly): the request is disallowed

This is a disaster, especially in the case where the domain has already
issued an HSTS header.

> 
>  B) (tbl's apparently proposal): go ahead with http fetch
> 
>  C) (brad hill's "optimistic" suggestion): try https version of
> requested resource instead
> 
> Compared to (B), (C) has no security flaws, since a network attacker can
> put arbitrary information into the request in (B), whereas the content
> of the resource in C is only whatever the resource's server is willing
> to produce via https.

I wouldn't be surprised if there were rare cases of (C) being a security
flaw for some obscure reason.  So maybe we should advocate (C) combined
with some level of broken security indication.  Perhaps not as strong as
red crossed out HTTPS, but a little exclamation mark triangle in place
of the lock icon could be fine.

> 
> I don't see a particular security flaw comparing (C) to (A) either, but
> maybe there is one i haven't noticed.
> 
> Anyway, if people are willing to consider (B), they certainly shouldn't
> reject (C) on security grounds.
> 
> 	--dkg
> 
> 



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