NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL
Lauren Weinstein writes: > Date: Sat, 14 Aug 2010 16:08:24 -0400 > From: Warren Kumari <warren@kumari.net> > Subject: Re: [ NNSquad ] Certified Lies: Detecting and Defeating Government > Interception Attacks Against SSL > > Hey Lauren, > > A few of us have been working on this in the past few months. The fact > that DNSSEC is finally getting traction and that the root is now > signed allows us to leverage the DNSSEC trust anchor as a trust anchor > for TLS. > > The very very high level view is that you publish a fingerprint (or > the key itself) in the DNS, and validate the DNSSEC signing when it > gets used. This allows the use of either CA or self-signed certs, and > validates that the key received is the correct one for the site -- > this also prevents the MITM hijacking attacks described in the paper > you referenced > > We held an informal BOF at the last IETF (IETF78 in Maastricht) and a > bunch of folk showed strong interest in working on this (and possibly > forming a Working Group). There are a few approaches, one of which is > detailed in > https://datatracker.ietf.org/doc/draft-hoffman-keys-linkage-from-dns/ > [0]. There are numerous other approaches from bright, well respected > members of the community as well, and I'm sure we will see more > proposals soon. It's really great to have more sources of information to double-check assertions from CAs. Recently at DEF CON my colleague Peter Eckersley presented some initial results from EFF's SSL Observatory certificate repository project; one of the most surprising things was the enormous number of intermediate CAs to which mainsream root CAs had delegated their authority. In mainstream browsers there is no simple way to refuse or override these delegations, which means that the intermediate CAs are as trusted as the roots. Amazingly, the SSL Observatory has found over 600 of them in active use on the Internet that would be trusted by the current version of Firefox or MSIE (or both), and there could be an unlimited number of others that are not in active use, or that are used only on private networks or only for targeted MITM attacks. Since we only find out about the existence of an intermediate CA when a site claiming to have been certified by that CA presents its certificate chain to us, there is no way to get a complete list. You can see a presentation about this at https://www.eff.org/observatory and you can also look at a map of the hundreds of intermediate CAs that Firefox or MSIE trust at https://www.eff.org/files/map-of-CAs.pdf The DNSSEC approach is much nicer in that there are many (many!) fewer entities who are in the position to facilitate undetected MITM attacks, particularly since it's clear who is supposed to be making particular assertions about particular services, rather than having an unlimited number of totally unknown entities who could all potentially make those assertions. On the other hand, the entities in the DNSSEC delegation chain are still in a position to sign delegations that are false. I guess the situation is also somewhat safer in the sense that it could be fairly detectable if, say, the root zone key signed a fake delegation for .com in order to help someone spy on mail.google.com, but I still feel concern conceptually about the existence of this power. Has anybody implemented any automated mechanism for clients to try to notify someone when DNSSEC delegations change? If we built a "Perspectives for DNSSEC", would it avoid the concerns that Andy Steingruebl raises about Perspectives at http://www.thesecuritypractice.com/the_security_practice/2010/04/perspectives-on-perspectives.html ? Because that would be pretty great, actually. -- Seth Schoen Senior Staff Technologist schoen@eff.org Electronic Frontier Foundation https://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 1 415 436 9333 x107