Hi Jeffrey-- I share your concerns about MitM attacks on the web, and I'm also not happy about the compromises made in HPKP about "locally-installed" trust roots, fwiw.
But i don't think your arguments are helping. On Sat 2015-02-21 21:38:20 -0500, Jeffrey Walton wrote: > You'll have to forgive my ignorance because the document states its > use to defend against some MitM attacks. The two canonical cases are > (1) Diginotar and (2) Superfish. We can defend against them with > pinning, so its not clear to me why browsers are having such trouble > with it. I believe pinning *would* prevent Diginotar misissuance, unless the origin server had pinned to the diginotar CA itself. All origin servers that had pinned to something other than the Diginotar CA would have their users reject any cert issued by Diginotar. Pinning doesn't defend against Superfish because Superfish is malware installed at system initialization time. It could have been a lookalike version of a popular browser, or just a replacement of a system library involved in certificate validation. The only technical defense against this kind of thing is to wipe your brand new system down as close to the bare metal as you can go and install it properly from known-good sources. Most people are not capable of doing this on most computers, though, so as a society our recourse against future Superfishes may need to be something beyond just the technical. > I think browser architects and the security community need a Key Usage > of INTERCEPT to help differentiate the cases. It will help browsers > and other user agents differentiate the "good" bad guys from "bad" bad > guys. It will also help them determine when its OK to break a known > good pinset. > > CAs surely won't issue INTERCEPT certificates and (I believe) most > folks won't declare INTERCEPT, so you've avoided the problem for a > majority of the use cases (over 90%?). That's a huge step forward in > helping browsers and other UAs differentiate the "good" bad guys from > "bad" bad guys. > > The "good" bad guys will honor it and you'll know you're dealing with > a "good" bad guy. The "bad" bad guys will not honor it and you'll know > you're dealing with a "bad" bad guy. In this case of a "bad" bad guy, > UAs should refuse to break the pinset. I can't tell if you're being serious here or not. It sounds like you're endorsing something very similar to: https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01 Which i think is a terrible idea. > And UAs won't fall victim to the Diginotar and Superfish cases. I'm quite certain that in your scenario, Superfish would have set themselves up as a "good" bad guy and the overwhelming majority of users would be none the wiser. --dkg _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
