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 [email protected] Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
