While researching some security-related stuff for a post I am currently writing, I found some interesting bits here and there that I though I should share, as they were new to me, and probably for many others.

DNSSEC

The first thing is DNSSEC. I knew about it, of course, but never bothered to dig much into it. While reading about many interesting applications of DNS for key distribution, and thinking of ways to use them, it is clear that DNSSEC is a precondition for any of that to work.

In case you don't know about it, it is an extension for the DNS service to make it safer, for example, to avoid the bad guys having you think that google.com points to sniffer.nsa.gov.

Apart from these über-cool applications I was thinking about, avoiding DNS-based attacks becomes more and more relevant these days. And I think Debian and the rest of the Free Software world should work on making this available to all end-users as easily as possible.

While adoption still looks pretty low, there are some good news.

First, Google claims its public DNS supports DNSSEC. Of course, you need to trust Google servers, and the path between your machine and them. But if your resolver supports DNSSEC, you can use their servers and validate the answers.

On the other side, I am not too sure about their implementation, as half of the time, it would return a valid answer to a query for an invalid record: dig +dnssec sigfail.verteiltesysteme.net @8.8.8.8). Also, they have not published DNSSEC records for google.com, which seems crazy.

Some packages included in Debian already take advantage of DNSSEC, if available (more on that later), but more importantly, there are a couple of DNSSEC-enabled recursive servers, including bind, unbound, and the more commonly-used dnsmasq (there is a wiki page summarising Debian's status). Sadly, the default configuration for dnsmasq does not enable DNSSEC, and most people will not use it, even if it installed, because DHCP-provided servers are usually preferred. It seems to me that it would be wise to have a package that would install dnsmasq with DNSSEC enabled, and make it the only valid resolver for the system.

If you want to check if your resolver is correctly validating DNSSEC, you can use this test web page.

Another good news is that many top-level domains already support DNSSEC, and in my case, Gandi.net has support in place to set it up. So I am going to look into enabling it for my own domain.

SSHFP

One useful and simple advantage of using DNSSEC, is that you can store information there, and then trust it to be correct.

One new DNS RR (resource record) that is useful in this context is the SSHFP RR, which allows the sysadmin of a host to publish the host SSH key fingerprint in the DNS zone.

The ssh client, when enabling the VerifyHostKeyDNS option, will use that information to trust unknown hosts. One downside to this, is that either if you set the option to ask, or if your resolver does not support DNSSEC, you get the same message, which does not warn you about the extra risk.

To help you create your DNS records, you can just run this command:

$ ssh-keygen -r brie.tincho.org
brie.tincho.org IN SSHFP 1 1 6ac93c63379828b5b75847bc37d8ab2b48983343
brie.tincho.org IN SSHFP 2 1 cf0d11515367e3aa7eeb37056688f11b53c8ef23

DANE, S/MIME and GPG

Recently, while at FOSDEM, I attended talks that mentioned DANE. This proposed IETF standard introduces a mechanism to use DNS as a secure key distribution system, which could completely override the CA oligopoly, a very attractive proposition for many people.

In short, it is very similar to the SSHFP mechanism, but it is not restricted to SSH host keys: it can be used to distribute public key information for any TLS-enabled service. So, instead (or in addition to) of having a CA sign your certificate, and relying on the chain of trust by means of having a local copy of all root CA certificates, you use the chain of trust embedded in DNSSEC to make sure that the DNS RRs you publish are valid. Then, the client application can trust the fingerprint published for the relevant service to verify that it is talking to the right server.

This is a very exciting development, and I hope it gets widespread adoption. It is already supported in Postfix, there seem to be some work going on in Mozilla, as well as in Prosody which is a great start.

Another exciting development of this, is the generalisation of DANE for other entities, like email addresses. There are two draft RFCs being worked on right now to deploy S/MIME and OpenPGP key material using DNSSEC. This could also change completely the way we manage the Web of Trust.

After quite a few hours of work, I finally switched completely to DNSSEC. Both client-side in my notebook, and in my personal tincho.org domain.

The client-side was pretty easy, although something broke in dnsmasq, but I had no patience to debug it, so I have just replaced it with a stock bind9 install, which is DNSSEC-enabled by default nowadays!

To complement that, I added a plugin to Firefox/Iceweasel (WNPP bug #672845 pending, downloadable from the Czech NIC) that shows me with a nice icon if the DNS is secure or not (and in the newest versions, it also shows DANE status, yay!).

So, basically, if you want to have DNSSEC support in your computer, just install unbound or bind9 (maybe dnsmasq, if you don't hit the same bug as me), it is really easy to have it up and running in no time.

To test if it is correctly working, apart from that nifty plugin, you can visit this funny web page from Verisign labs.

On the server side, it was trickier. It involves quite a few steps, and the default tools from package dnssec-tools are pretty buggy. But it was not too bad. After moving my domain from the registrar's DNS to my own server, configuring secondaries, etc. I went ahead with the DNSSEC configuration. I used this pretty good DNSSEC howto, which made the process a lot easier.

After having my DNS server ready, I added the DS records in my registrar, and voilà, tincho.org is now protected by DNSSEC!

There are a few web services to test your deployment, a simple one, and a more complete one with GraphViz diagrams!

I felt so bold with all this, that I went ahead and created DANE and SSHFP records for my services (and had to debug issues with SSH, because the old ssh-keygen tool would not create ECDSA records). And even set Postfix to use DANE to connect to remote hosts. Let's see how many things break in the following days!