On 27/11/15 23:43, Jeffrey Walton wrote: > On Fri, Nov 27, 2015 at 5:47 PM, Greg <g...@kinostudios.com> wrote: >> Thought this list would be interested in reading about the roll that Google >> played in compromising 100k+ users (in addition to Dell): >> >> https://www.reddit.com/r/crypto/comments/3u92aw/dells_tumble_googles_fumble_and_how_government/cxejl5y > > They seem to be missing the issue (if I am parsing it correctly): > > REDDIT > So you are saying that Chrome should roll out its own > REDDIT > cert store because relying on Windows 10's cert store is > REDDIT > insecure? > REDDIT > > REDDIT > Sorry your argument seems very weak and odd to me. > REDDIT > It also detracts away from the severity of what Dell has done. > > That's not Chrome or Windows per se. Rather, that it is a feature of > the Web/Browser security model. In the security model, proxying and > interception is a valid use case. You can thank the browser > (in)security engineers for that. > > It not just limited to W3C participants. The IETF just jumped on the > "proxying and interception is a valid use case" bandwagon with RFC > 7469, "Public Key Pinning with Overrides"
That is not actually the title of that RFC. > (https://tools.ietf.org/html/rfc7469). Checkout section 4, and then > try to find what the override is supposed to do, or additional > information or guidance on using it. I'm not a fan of that override stuff myself (which is in 2.6 and not in section 4 btw) but weren't you yourself [1] a part of that discussion in the websec wg? While you may have joined in that part of the discussion too late to affect the outcome, I think characterising this is "just jumped on ... bandwagon" isn't fair nor accurate. [1] https://www.ietf.org/mail-archive/web/websec/current/maillist.html > > Finally, don't look to the IETF to help distinguish the "good" bad > guys from the "bad" bad guys when a conforming user agent does > override (or tries to decide if it should override). I've been trying > to discover that myself. See "How do we differentiate authentic > servers from proxies performing TLS interception", > https://www.ietf.org/mail-archive/web/pkix/current/msg33425.html. > > And finally (and either humorously or sadly, depending on your state > of mind), the PKIX's position is there's no difference between > authentic server authentication and an imposter pretending to be an > authentic server. They are happy to allow a CA to issue certificates > for either usage, even though they appear to be as diametrically > opposed as you can get. IMO the above is a mis-characterisation of the situation and of the recent discussion on the p...@ietf.org mailing list. My read of that discussion is that a number of people stated a number of times that no matter how much one would like some bit in a protocol to distinguish real authentication vs. a MitM with a locally installed trust point, there's just no way that can work. I saw that you seemed to disagree with that, but tbh I've no idea how what you want could work. What you're after can't be provided by the IETF. I do agree that implementations could handle overrides differently in ways that would make it harder do be a MitM. I'd also point you at RFC2804 and BCP200 which are other relevant IETF publications. Cheers, S. > > The NSA and GCHQ does not need to limit cryptography or algorithms. > They just need more browser (in)security engineers in more working > groups. > > Jeff > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
