NNSquad - Network Neutrality Squad

NNSquad Home Page

NNSquad Mailing List Information


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ 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


and you can also look at a map of the hundreds of intermediate CAs
that Firefox or MSIE trust at


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


?  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