|
There has been quite a bit of talk lately about the best way to secure a domain, mainly centered in two camps: using Secure Socket Layer (SSL), or using DNS Security Extensions (DNSSEC). The answer is quite simple—you should use both.
The reason for this is that they solve different problems, using different methods, and operate over different data. This is analogous to having an electronic security system and a very large dog. Both protect the house, but they do it in radically different ways (very few burglars have been bitten by a surveillance system). To better understand this, we need to examine how each system works, what it does, and, more specifically, what it doesn’t do.
Secure Socket Layer, or SSL, is a system used to encrypt data and authenticate the sender (in this case, the sender is the website you’re connecting to). To facilitate the encryption, the folks running the web site must obtain what’s known as an SSL Certificate. Think of it like a birth certificate: it says “yes, this website is who they claim to be”. This certificate contains a public and a private electronic key, which is used to establish a secure channel (called a session) between your browser and the web site. With the session established, all data passing between the website and your browser is encrypted—to anyone snooping around on the network, looking at your packets, it appears garbled.
DNS Security Extensions (DNSSEC) doesn’t work with websites at all—it’s all done behind the scenes, before any web-stuff occurs. When a home computer uses DNSSEC to try to find a web site’s address, it not only performs the normal DNS lookup, it also validates a signature returned from the DNS server. This happens at all levels, from the “root servers”, through the Top Level Domain (e.g. .org or .info) all the way down to the specific address that you requested ( www.example.org ). If all of these signatures are validated, then the answer is sent to the browser to connect to the web site (and maybe using SSL to do so).
So why not just use one or the other? Let’s start with just using SSL. Remember the birth certificate analogy? The certificates come from establishments known as Certificate Authorities, or CAs (this is the “hospital”). The problem is that some CAs are not trustworthy, and will issue certificates without checking any data on the company itself. This means that anyone could, using the right CA, be issued a certificate for www.example.org. It is also possible for people to “self-sign” a certificate—in effect, becoming their own hospital. Many phishing sites do this now, and make their certificate look as legitimate as possible.
Using just DNSSEC isn’t fool proof either. Even though you have completely determined that the “chain of trust” has been followed all the way down from the root DNS servers, you now have to transmit sensitive data to a Web site (such as your bank account login and password). DNSSEC does not do any data encryption on the DNS, and isn’t involved at all once the web interaction has started. This means that anyone watching your network (which, on WiFi, is very easy to do these days) could easily steal your information.
So, in conclusion, using DNSSEC and SSL is not simply a “belt and suspenders” rule—it’s more of a “shirt and pants” rule. Using either is good, but using both will increase your security significantly, causing the least, um, exposure.
Sponsored byWhoisXML API
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byRadix
Sponsored byVerisign
[Note: SSL has been advanced and standardised as TLS: Transport Layer Security. It is used not only in conjunction with HTTP (where it is known as HTTPS), but also in several other TCP-based protocols (e.g. SMTP and its variants).]
“Defence in depth” is an approach where obstacles are placed in the way of an attacker such that he must overcome all of them. A real-world example is a castle with a moat: you have to get over the moat and the castle walls to penetrate the castle, and the presence of the moat makes it more difficult to position siege engines against the castle wall. Of course, the “in depth” part still assumes a certain mode of attack, and all the clever security means nothing if the attackers choose a mode which bypasses these defences. Moats and walls are no defence against a Trojan Horse.
Is the combination of DNSSEC and SSL defence in depth?
If your threat is the classic “man in the middle attack”, then you need SSL/TLS more than you need DNSSEC. In a world without DNSSEC (i.e. the world most of us live in), such an attacker can easily direct you to the wrong place, but you’ll know it’s the wrong place when you get there, so the attack fails. In a world with DNSSEC but not SSL/TLS, the attacker can’t steer you in the wrong direction, but he can intercept you on the way, and you’ll be none the wiser.
This analysis should give us pause for thought. DNSSEC is supposed to defend against MITM (man in the middle) attacks, and it does so to some degree (by protecting the name-to-address resolution process), but it relies on SSL/TLS to finish the job. One of the arguments used in favour of DNSSEC is that SSL/TLS isn’t working all that well in practice, so we need the additional security of DNSSEC. Unfortunately, DNSSEC isn’t actually providing additional security against a genuine MITM attack: SSL/TLS is still the weak link in the chain when DNSSEC is used!
DNSSEC plus SSL/TLS is therefore not defence in depth against general MITM attacks. The MITM attacker can ignore the entire DNS process and simply intercept data between the client and server, attacking only the SSL/TLS protection. DNSSEC provides protection against a special case of MITM attack: where the MITM interferes with DNS results. SSL/TLS provides general coverage of MITM attacks, including this special case. SSL/TLS won’t reveal whether the attack uses DNS interference or address impersonation, but it can detect both cases.
The “additional coverage” provided by DNSSEC is thus extremely limited. If a service is already protected by SSL/TLS, then DNSSEC can only provide additional security in the following extremely specific circumstances: the attacker must be able to compromise the SSL/TLS process, and the attacker must rely on interference with the DNS to launch the attack, but prevented from doing so by DNSSEC.
Here’s the core of the problem with DNSSEC as relates to it providing security of any sort: it’s a complex system which can only compensate for special-case failures of a similarly complex (but more mature) system. Current events are demonstrating that there are problems in many SSL/TLS implementations, but they are being fixed. Initial deployments of DNSSEC will be fresh full of new and undiscovered flaws, whereas the existing deployments of SSL/TLS have been subject to trial by fire. Practically speaking, I think we’d be better served by attempting to fix the problems with SSL/TLS: it addresses the problem at its heart, and it builds on a base of tried and tested technology.
One of the nice features of DNSSEC is that the people issuing the domain names are also responsible for the signature chain which validates them. Stupid question: why don’t we do this for SSL/TLS? Why aren’t certificates for domain names provided by the parties that actually make the domain name assignments?