Links

Ben Laurie blathering

12 Sep 2011

DNSSEC on the Google Certificate Catalog

Filed under: DNSSEC,Security — Ben @ 14:47

I mentioned my work on the Google Certificate Catalog a while back. Now I’ve updated it to sign responses with DNSSEC.

I also updated the command-line utility to verify DNSSEC responses – and added a little utility to fetch the root DNSSEC keys and verify a PGP signature on them.

As always, feedback is welcome.

3 Apr 2011

Improving SSL Certificate Security

Filed under: Crypto,DNSSEC,Security — Ben @ 19:47

Given how often I say on this blog that I am not speaking for my employer, I am amused to be able to say for once that I am. Over here.

2 Dec 2010

P2P DNS

Filed under: DNSSEC — Ben @ 14:10

Apparently the Pirate Bay are tired of ICANN and want to start their own peer-to-peer DNS. I think their chances of wide adoption are pretty near zero, but it’s an interesting area that’s needed serious exploration for quite some time. Obviously if you’re doing P2P DNS you need to use DNSSEC or attacks become trivial. Since they also want to have multiple registrars who can nominate themselves, it seems a proposal I made to the DNS working group many years ago could be handy. Basically, the idea is to distribute keys for “islands of security” by having bilateral agreements between them, so each island signs some set of other island’s keys, if they want to. The user then bootstraps their set of keys by starting from an island or islands they trust.

When ferreting this out I found that the -01 version is already on my server, and I just uploaded -02 – not sure what the differences are, when I have some time I’ll make a diff. Probably.

26 Jun 2009

Who Pwns The Internet? (Take Two, Part Two)

Filed under: DNSSEC,Security — Ben @ 6:20

I actually got these done over the weekend, but I’ve been kinda busy. After taking a more, ahem, principled approach, France seems less dramatic

France by AS

but still pretty impressive. If you take a close look you’ll see I’ve also had a crack at adding the AS’ owner as well (not 100% reliable, if anyone knows how, let me know!). The UK depends on one less AS than before

UK by AS

and I can do Fiji

Fiji by AS

I still can’t do the world, though – but now the problem is that dot chokes on the graph.

20 Jun 2009

Who Pwns The Internet? (Take 2)

Filed under: DNSSEC,Security — Ben @ 20:08

Another interesting way to pwn the Internet is to control the routing of packets to critical nameservers. In practice, Internet routing is done by ASes (Autonomous Systems). If an AS wants to pwn a nameserver on a network it controls, it is a trivial matter: it just redirects the packets to its own nameserver. I’d draw you a picture, but I’m sure Matasano Chargen will do it prettier.

So. I thought it would be instructive to determine which ASes had control over which domains. More fun with dot.

The picture is no longer quite so rosy for the UK, but still, not bad, all things considered.

UK's AS dependencies

But France. I don’t know what to say about France. France is surreal. I’ve linked through to a much bigger version because, well, you’ve got to lose yourself in the spiderwebs. The SVG is here, though.

Small version of France's AS dependencies

As for Fiji, I’d love to show you Fiji, but the way I’m doing it doesn’t work for Fiji right now. And hence, obviously, not for the whole world, either. Coming soon, I hope.

14 Jun 2009

Who Pwns The Internet?

Filed under: DNSSEC,Security — Ben @ 16:22

Update: Ben Hyde suggested I should use the (undocumented) “concentrate” option to dot, which certainly tidies up the graphs. So I did.

A remark on the IETF DNS Working Group’s mailing list got me thinking.

Suppose I were the owner of nordu.net (to pick an example at random), then I could take control of sunet.se, for about 25% of Internet users, since one of their four nameservers is server.nordu.net. Similarly, I could then take control of ripe.net for 25% of those 25% (via sunic.sunet.se). One in seven of those guys could fall victim to my ownership of nic.fr via ns-sec.ripe.net, and from there I have complete control of fr (that is, France) – ok, by now, for only a bit under 1% of the Internet, but even so, that’s kinda worrying, don’t you think? And obviously if I own sunet.se then it would be more like 3.5%…

On the other hand, uk does not suffer from this problem: it depends only on nic.uk. Which seems like a much better idea. Anyway, I got to wondering just how bad this problem actually is, which led to me having more fun with dot. So, for a taster, here’s France’s dependencies…

France's dependencies

And here’s the UK’s

UK's dependencies

And here’s Fiji (I include this for Jasvir, who is getting married there soon, and ought to know the terrible risk he’s taking)

Fiji's dependencies

And all the top level domains put together

All TLDs' dependencies

So that one is pretty but a bit hard to digest. Obviously the main news is that there are a lot of domains which could interfere with one or more TLDs!

Another way to think about this is to wonder who could pwn the most TLDs? Well, the answer (after the root, of course) is that nstld.com, gtld-servers.net, com and net come in equal first with 228 TLDs pwnable. Next up is Affilias, through a variety of domains, including org and info, able to control 187 TLDs. After that comes se (Sweden) with 158 and nordu.net, sunet.se, chalmers.se, kth.se, uninett.no, uu.se, edu, no, norid.no, lth.se and uit.no, all able to have a go at 157 TLDs.

Food for thought. Especially if you’re thinking about DNSSEC.

7 Mar 2009

DNSSEC: Update

Filed under: DNSSEC — Ben @ 18:26

I’ve had feedback since I wrote about DNSSEC that my makefile didn’t work on many platforms. Why Linux and FreeBSD have to use different versions of make I have no idea, but at least it is possible to write makefiles that work on either, if you’re careful. So, I’ve updated the tarball with a version that should work most places. Give it a try.

For the geeky, here’s a diff:

iff -r 94acb807ca7c -r d4a50f0d790c Makefile
--- a/Makefile  Sat Mar 07 16:41:39 2009 +0000
+++ b/Makefile  Sat Mar 07 16:49:37 2009 +0000
@@ -1,4 +1,6 @@
 all: run
+
+.PHONY: named.root anchors.xml isc-dlv.conf
 
 push: dnssec.tgz
        scp dnssec.tgz www.links.org:files
@@ -6,7 +8,7 @@
 run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
        named -c named.conf -d 10 -g
 
-named.root!
+named.root:
        rm -f named.root
        wget ftp://ftp.rs.internic.net/domain/named.root
 
@@ -17,7 +19,7 @@
        ./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
        mv /tmp/itar-trusted-keys itar-trusted-keys.conf
 
-anchors.xml! iana-pgp-keys
+anchors.xml: iana-pgp-keys
 # appears to break without -v!
        rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
        gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
@@ -46,7 +48,7 @@
        gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
        rm isc-key.tmp* 363
 
-isc-dlv.conf! isc-pgp-keys
+isc-dlv.conf: isc-pgp-keys
        rm -f dlv.isc.org.named.conf*
        wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
        gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.conf

24 Feb 2009

Doing DNSSEC Right

Filed under: DNSSEC,Security — Ben @ 16:36

Since posting about DNSSEC, I’ve had lots of great feedback. So, in no particular order…

Various people have pointed out that DLV is not as bad as I suggested

  • DLV is only activated for queries that cannot be proved secure in the cache
  • DLV employs aggressive negative caching – it works out whether existing cached NSEC (and NSEC3?) records would prove nonexistence of a record before bothering to query it
  • DLV is not used for domains that have trusted keys

Although the second measure is, as I remember it, strictly speaking against the rules (one is not supposed to calculate negative responses from the cache), clearly it can be stipulated that a DLV server must behave when serving NSEC records. Anyway, the net result is that the overhead of DLV is actually quite reasonable. I still say it should be run by every DLVed domain for every other, though. In any case, I am going to switch it on in my own caching resolver.

One thing I wanted to achieve is that a DNSSEC-ignorant resolver downstream of my caching resolver would only get validated results. I tried to do this with the dnssec-must-be-secure configuration option – but this is wrong. That option requires everything to be signed, whereas in DNSSEC it is perfectly OK for a zone to be unsigned so long as its parent delegates to it with no keys (bear in mind that with DNSSEC the nonexistence of the keys is provable, and so this is secure). In fact, BIND 5.3 behaves as I want it to with just DNSSEC enabled. In BIND 5.4 onwards I will have to switch it on with the dnssec-validation option (gee, thanks, ISC for making a backward incompatible change!).

Jelte Jansen operates a domain with various broken entries – this is very handy for testing and I now include its key in my configuration. Note that if you want to see a record that fails validation, then you need to set the CD bit (with dig, +cd or +cd +dnssec if you want to see the DNSSEC records).

Paul Hoffman wonders why I would prefer a signature (for anchors2keys) to download over HTTPS. The reason is that HTTPS download doesn’t really prove the file hasn’t been interfered with – the server will serve anything that happens to be in the filesystem over HTTPS, of course. A signature would be done with a key that I would hope is very strictly supervised, and so is far more trustworthy.

Incidentally, for DNSSEC newbies, one of the interesting features of DNSSEC is that it can be done entirely with offline keys. Proving negatives (i.e. the nonexistence of names) with such a constraint is an interesting problem – and one that I spent three years working on, leading in the end to RFC 5155.

I’m sure everyone is tired of reading my config and makefile, so there’s a tarball here.

Finally, thanks very much to all the experts for the excellent feedback.

22 Feb 2009

DNSSEC With DLV

Filed under: DNSSEC,Security — Ben @ 18:38

Tony asks “what about DLV?”.

DLV is Domain Lookaside Validation. The idea is that if your resolver can’t find a trust anchor for foo.bar.example.com, then it can go and look in a lookaside zone, hosted at, say, dlv.isc.org, for trust anchors. So, it would first look for com.dlv.isc.org and then example.com.dlv.isc.org and so forth.

So, what do I think of this? It’s another way to solve the problem of having the root not signed.

How does it compare to IANA’s ITAR?

  1. It’s much less efficient – all those extra lookups for every query.
  2. It covers more than just TLDs – ITAR could, too, but it doesn’t, for whatever reason.
  3. There doesn’t seem to be a way to force it, like there is for ITAR. That is, I would like to configure my caching server to force DNSSEC for every domain that exists in DLV, but I don’t believe I can. This makes DLV practically useless, since now only clients that check the AD bit will be aware of the failure.

Also, I think it would be organisationally better if all the participating domains would run DLV for each other, rather than have any single party running it.

Anyway, I modified my setup to also use DLV. Here’s the new Makefile

all: run

run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
	named -c named.conf -d 10 -g

named.root!
	rm -f named.root
	wget ftp://ftp.rs.internic.net/domain/named.root

rndc.key:
	rndc-confgen -a -c rndc.key

itar-trusted-keys.conf: anchors2keys anchors.xml
	./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
	mv /tmp/itar-trusted-keys itar-trusted-keys.conf

anchors.xml! iana-pgp-keys
# appears to break without -v!
	rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
	gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml

anchors2keys:
	wget --no-check-certificate https://itar.iana.org/_misc/anchors2keys
	chmod +x anchors2keys

iana-pgp-keys:
	html2text -nobs http://www.icann.org/en/general/pgp-keys.htm > iana-pgp-keys.tmp
# IANA's PGP keys suck. Clean them up...
	awk '/^>/ { print substr($$0,2,100); next; } /^Version:/ { print; print ""; next; } { print }' < iana-pgp-keys.tmp > iana-pgp-keys.tmp2
	gpg --import iana-pgp-keys.tmp2
	gpg --export 81D464F4 | gpg --no-default-keyring --keyring ./iana-pgp-keys --import
	rm iana-pgp-keys.tmp*

force-dnssec.conf: itar-trusted-keys.conf
	awk '/^"/ { gsub(/"/, "", $$1); print "dnssec-must-be-secure \"" $$1 "\" true;"; }' < itar-trusted-keys.conf | sort -u > force-dnssec.conf

isc-pgp-keys:
	rm -f 363
	wget --no-check-certificate https://www.isc.org/node/363
	html2text < 363 > isc-key.tmp
	awk '/^Version:/ { print; print ""; next; } { print }' < isc-key.tmp > isc-key.tmp2
	gpg --import isc-key.tmp2
	gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
	rm isc-key.tmp* 363

isc-dlv.conf: isc-pgp-keys
	rm -f dlv.isc.org.named.conf
	wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
	gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.conf
	mv dlv.isc.org.named.conf isc-dlv.conf

test:
	dig -p5453 +dnssec www.dnssec.se @localhost

and here’s named.conf

options {
  listen-on port 5453 { 127.0.0.1; };
  pid-file "named.pid";
  dnssec-enable true;
  dnssec-lookaside . trust-anchor dlv.isc.org.;
  include "force-dnssec.conf";
};

// obtain this file from ftp://ftp.rs.internic.net/domain/named.root
zone "." { type hint; file "named.root"; };

// include the rndc key
include "rndc.key";
controls {
  inet 127.0.0.1 port 1953
    allow { 127.0.0.1; }
    keys { "rndc-key"; };
};

// include ITAR trust anchors
include "itar-trusted-keys.conf";

// include ISC DLV trust anchor
include "isc-dlv.conf";

Enjoy.

Incidentally, I have enabled “forced ITAR” on my main resolver, so we’ll see how that goes. I haven’t added DLV because, like I say, failure would not be noticed, so what’s the point of all the overhead?

What Is DNSSEC Good For?

Filed under: Crypto,DNSSEC,Security — Ben @ 18:24

A lot of solutions to all our problems begin with “first find a public key for the server”, for example, signing XRD files. But where can we get a public key for a server? Currently the only even slightly sane way is by using an X.509 certificate for the server. However, there are some problems with this approach

  1. If you are going to trust the key, then the certificate must come from a trusted CA, and hence costs money.
  2. Because the certificate is a standard X.509 certificate, it can be used (with the corresponding private key, of course) to validate an HTTPS server – but you may not want to trust the server with that power.
  3. The more we (ab)use X.509 certificates for this purpose, the more services anyone with a certificate can masquerade as (for the certified domain, of course).

One obvious way to fix these is to add extensions to the certificates that prevent their use for inappropriate services. Of course, then we would have to get the CAs to support these extensions and figure out how to validate certificate requests that used them.

But I have to wonder why we’re involving CAs in this process at all? All the CA does is to establish that the person requesting the certificate is the owner of the corresponding domain. But why do we need that service? Why could the owner of the domain not simply include the certificate in the DNS – after all, only the owner of the domain can do that, so what further proof is required?

Obviously the answer is: DNS is not secure! This would allow anyone to easily spoof certificates for any domain. Well, yes – that’s why you need DNSSEC. Forgetting the details of DNSSEC, the interesting feature is that the owner of a domain also owns a private key that can sign entries in that domain (and no-one else does, if the owner is diligent). So, the domain owner can include any data they want in their zone and the consumer of the data can be sure, using DNSSEC, that the data is valid.

So, when the question “what is the public key for service X on server Y?” arises, the answer should be “look it up in the DNS with DNSSEC enabled”. The answer is every bit as secure as current CA-based certificates, and, what’s more, once the domain owner has set up his domain, there is no further cost to him – any new keys he needs he can just add to his zone and he’s done.

Does DNSSEC have any other uses? OK, it would be nice to know that the A record you just got back corresponds to the server you were looking for, but if you trust a connection just on the basis that you used the right address, you are dead meat – you’ll need some key checking on top of it (for example, by using TLS) to avoid attacks by evil proxies (such as rogue wifi hotspots) or routing attacks and so forth. For me, the real value in DNSSEC is cryptographic key distribution.

Using DNSSEC Today

Filed under: DNSSEC,Security — Ben @ 15:54

It’s been a while since I’ve properly paid attention to developments in the DNSSEC world, so I was surprised to learn that IANA now has an “Interim Trust Anchor Repository“. No need to wait any longer for the root to be signed, you can configure yourself to do DNSSEC right now.

Here’s how. First off, grab this Makefile

all: run

run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf
	named -c named.conf -d 10 -g

named.root!
	rm -f named.root
	wget ftp://ftp.rs.internic.net/domain/named.root

rndc.key:
	rndc-confgen -a -c rndc.key

itar-trusted-keys.conf: anchors2keys anchors.xml
	./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
	mv /tmp/itar-trusted-keys itar-trusted-keys.conf

anchors.xml! iana-pgp-keys
# appears to break without -v!
	rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
	gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml

anchors2keys:
	wget --no-check-certificate https://itar.iana.org/_misc/anchors2keys
	chmod +x anchors2keys

iana-pgp-keys:
	html2text -nobs http://www.icann.org/en/general/pgp-keys.htm > iana-pgp-keys.tmp
# IANA's PGP keys suck. Clean them up...
	awk '/^>/ { print substr($$0,2,100); next; } /^Version:/ { print; print ""; next; } { print }' < iana-pgp-keys.tmp > iana-pgp-keys.tmp2
	gpg --import iana-pgp-keys.tmp2
	gpg --export 81D464F4 | gpg --no-default-keyring --keyring ./iana-pgp-keys --import
	rm iana-pgp-keys.tmp*

force-dnssec.conf: itar-trusted-keys.conf
	awk '/^"/ { gsub(/"/, "", $$1); print "dnssec-must-be-secure \"" $$1 "\" true;"; }' < itar-trusted-keys.conf | sort -u > force-dnssec.conf

and this named.conf

options {
  listen-on port 5453 { 127.0.0.1; };
  pid-file "named.pid";
  dnssec-enable true;
  include "force-dnssec.conf";
};

// obtain this file from ftp://ftp.rs.internic.net/domain/named.root
zone "." { type hint; file "named.root"; };

// include the rndc key
include "rndc.key";
controls {
  inet 127.0.0.1 port 1953
    allow { 127.0.0.1; }
    keys { "rndc-key"; };
};

// include ITAR trust anchors
include "itar-trusted-keys.conf";

and run make. After a while, with luck, you’ll have named with trust anchors configured (you can see which ones by looking at itar-trusted-keys.conf) running on port 5453 (and the rndc control channel on port 1953).

You can test it with, for example

$ dig -p5453 +dnssec www.dnssec.se @localhost      

; < <>> DiG 9.3.5-P2 < <>> -p5453 +dnssec www.dnssec.se @localhost
;; global options:  printcmd
;; connection timed out; no servers could be reached
[ben@euphrates ~/svn-work/peim/doc]
$ dig -p5453 +dnssec www.dnssec.se @localhost

; < <>> DiG 9.3.5-P2 < <>> -p5453 +dnssec www.dnssec.se @localhost
;; global options:  printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 41806
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec.se.                 IN      A

;; ANSWER SECTION:
www.dnssec.se.          300     IN      CNAME   dnssec.iis.se.
www.dnssec.se.          300     IN      RRSIG   CNAME 5 3 300 20090302080001 20090220080001 62658 dnssec.se. y0JcIxVunryZRaccDX2PteGyxCQ2dlfeoeDYNcoPKCryBa9vGWuNJwNa MhqzMmLLr5N4SbQsIL8YrQ8+l/wBFebXB6I8dJ8OWDmz6OqihSzkDYB/ qFwEWLQi49RfCuE6Qai/PnPh0Om+7guyL15fLTMh3PtZso4axt23/vqG 5RI=
dnssec.iis.se.          3600    IN      CNAME   www.iis.se.
dnssec.iis.se.          3600    IN      RRSIG   CNAME 5 3 3600 20090302135501 20090220135501 6477 iis.se. ebDsJcmZRHkq5Y+SLTIC2Iey3fNBj7r3bk3TAeyJPXtgFE6YJqAtJmv4 m5Sn1jDZhidnI0NWyPz5dUwDFfzVnJN/DH+CZJuiynKQge4inIGt8Dzk ybaq7JSoFkHABAu+IBbVKwR4+TW92tzv2CgzdtBIsQnuOn+CQMpmuz+N rFk=
www.iis.se.             3600    IN      A       212.247.7.210
www.iis.se.             3600    IN      RRSIG   A 5 3 3600 20090302135501 20090220135501 6477 iis.se. aIOT7U/CRcFi3CcgaHp6EqV8JHkODodQM0Pg7CKh1gby4/8pGnqABDiU +4bg8/zDlAzVUz6o4j5sjIg5uS2A1ODJzp+UodXyVL9/Q8eBfZGSDuOa FPwK9jUxj6P1iXIqoMyeAS1PG1rFgSim/xpZLhJK2l5ScQ/1+Pq6SG8T Lgc=

;; Query time: 1236 msec
;; SERVER: 127.0.0.1#5453(127.0.0.1)
;; WHEN: Sun Feb 22 14:07:14 2009
;; MSG SIZE  rcvd: 602

Because we have forced DNSSEC on the trusted domains (this is done in the included file force-dnssec.conf), the fact we get an answer at all tells us that the signatures checked out – but also the fact that the AD bit is set (“;; flags: ... ad ...“) tells you that the signatures were validated by the caching server you just set up. Note that pretty much no application will check for the AD bit, so DNSSEC is only really going to help if you have it forced on, as in this configuration. Obviously if you want to run this for real, you should run it on standard ports and point all your resolvers at it. Then you get the benefits of DNSSEC today with no application changes.

Note that ordinary queries (i.e. ones that don’t request DNSSEC) are also validated by the server, but we don’t see the DNSSEC stuff in the response

$ dig -p5453 www.dnssec.se @localhost

; < <>> DiG 9.3.5-P2 < <>> -p5453 www.dnssec.se @localhost
;; global options:  printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 2159
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec.se.                 IN      A

;; ANSWER SECTION:
www.dnssec.se.          100     IN      CNAME   dnssec.iis.se.
dnssec.iis.se.          3400    IN      CNAME   www.iis.se.
www.iis.se.             3400    IN      A       212.247.7.210

;; AUTHORITY SECTION:
iis.se.                 86200   IN      NS      ns3.nic.se.
iis.se.                 86200   IN      NS      ns.nic.se.
iis.se.                 86200   IN      NS      ns2.nic.se.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#5453(127.0.0.1)
;; WHEN: Sun Feb 22 14:41:25 2009
;; MSG SIZE  rcvd: 147

I notice that the AD bit isn’t set, though, which seems like a bug.

Powered by WordPress