SSL certificates are blobs of bytes which are used by Web clients and servers to authenticate each other. Say you visit your favorite online shop with a Web browser, your browser will (hopefully) be presented with an SSL certificate “proving” the identity of the server. The server’s operator has configured her Web server to present that certificate to your browser.
The problem here is in the “proof”. How does the server prove anything? Well, the operator has purchased a certificate from a certification authority (CA). The CA in effect confirms “yes, I know that company, and they have a server called wwww.someplace.org”. On the other hand, your Web browser is delivered to you containing a number of CA certificates. When the CA signs the server certificate, your browser – as it trusts the CA certificate – implicitly trusts the certificate signed by the same CA for the server.
All this comes at a price: there are a large number of Certification Authorities (too many if you ask me), who have differing rules and policies as to how to obtain proof from a server operator, and of course, a certificate costs, usually, an annual fee.
Enter the DNS.
For some time there have been different standards for storing certificate material in the DNS, none of which have really taken off because of the inherent insecurity of the DNS. But, with the advent of DNSSEC, a new page is opened.
With DNSSEC, I am able to sign the data in the DNS, thereby assuring to DNS clients which validate these signatures, that the replies to queries they sent actually originated from my DNS server and where not tampered with in transit.
Effectively this sets me up as a kind of “DNS certification authority” for my DNS domains; when you get a signed reply, and if you can verify that signature, you know that it is I who created the data in the response.
Since becoming interested in DNSSEC, I’ve been very interested in getting SSL certificate material into the DNS.
The first attempt was done by Dan Kaminski with Phreebird: he proved it is
possible by creating an
LD_PRELOAD library that would instruct OpenSSL that
the certificate it just received is trusted.
Another implementation has now been attempted by Danny Groenewegen and Pieter Lange. What they did was to implement a Firefox 4.0 plugin called the Extended DNSSEC Validator which launches its own Unbound resolver as a shared object. The plugin verifies whether the domain I’m connecting to is DNSSEC-signed and whether it contains a particular record with the site’s certificate fingerprint. If so, the server’s SSL certificate is trusted and the user isn’t confronted with those ugly “are you sure?” dialogs.
I was able to get the add-on to work although, as its authors confess, it still has a number of rough edges. In particular I could only make it work on Linux. On Mac OS/X, despite “downgrading” to a prior Firefox beta version, it didn’t do anything.
I first created a self- signed SSL certificate with OpenSSL, which I used to set up a minimal SSL- enabled Web server.
As per the technical description of the plugin, I created the fingerprint and the corresponding TXT record in the DNS [using my very own phreefingerprint]. The plugin checks for the existence of TXT records (easier for most people to handle) and for TLSA records (a hopefully oncoming standard).
So, will it blend? :-) Let’s see what happens when, with a clean Firefox install, I go to my site:
It works. No dialogs, no prompting, no nothing. Remember, this is a self-signed certificate! And if I click on the icon in the toolbar?
And a glance in Firefox’ certificate manager shows the temporary certificate.
Unfortunately, this is all still a bit wobbly: sometimes it works, sometimes it doesn’t. But that doesn’t matter: I like the ideas behind the implementation.
I’d like this in all Web browsers. Natively implemented in order to diminish the number of DNS requests issued. Certification Authorities are not going to like this, as it effectively renders them a bit superfluous.