Securing a Domain: SSL vs. DNSSEC

Home / Blogs

Securing a Domain: SSL vs. DNSSEC

	By Howard Eland Senior Director, Content Propagation and Resolution, Afilias
	October 07, 2009 Views: 29,626 Comments: 4

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.

By Howard Eland, Senior Director, Content Propagation and Resolution, Afilias

Filed Under

Comments

Is DNSSEC+SSL defence in depth? The Famous Brett Watson – Oct 8, 2009 3:43 AM

[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?

# 1 Reply | Link | Report Problems

In a world without DNSSEC (i.e. the Howard Eland – Oct 8, 2009 1:26 PM

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.

I disagree with this statement. The typical end user may not know if it failed or not sans DNSSEC. If someone were to poison the end user's DNS cache with a bad IP for well-known banks, setup a sort of http(s)-proxy with a set of bad certs for these institutions, the end user would be none the wiser. This is why I advocate both DNSSEC and SSL/TLS - they work on inherently different problems. Neither is sufficient by themselves.

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!

Once again, DNSSEC is handling a completely different vector within the attack. The weakest link sans DNSSEC is not SSL/TLS, it's DNS cache poisoning. DNSSEC is exactly providing the additional security against this. Once DNSSEC is in place, the weakest link is now SSL/TLS. I do agree that DNSSEC with SSL/TLS is not defense in depth, but perhaps for a slightly different reason - they work on different problem sets. The castle is being defended with both trebuchet and boiling oil pots. The oil is ineffective against archers, and the trebuchet doesn't work on the infantry climbing the walls. However, used in conjunction (and with other defenses), they are formidable.

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.

Not deploying software because it's new is not much of an argument - nothing would ever be implemented. From that perspective, SSL/TLS should never have gotten out the door.

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.

I absolutely agree with you - let's get SSL/TLS fixed (although not having a single SEP for CAs is a tough nut to crack). But, let's also make sure we handle these other problems as well. Let's deploy DNSSEC (and fix those bugs that will come with it). Let's also watch out for phishing attacks, run virus scans, and stop putting passwords on a Post-It©

# 2 Reply | Link | Report Problems

Comments and corrections The Famous Brett Watson – Oct 8, 2009 5:38 PM

If someone were to poison the end user's DNS cache with a bad IP for well-known banks, setup a sort of http(s)-proxy with a set of bad certs for these institutions, the end user would be none the wiser. This is why I advocate both DNSSEC and SSL/TLS - they work on inherently different problems.

This attack scenario is an example of the special case that I pointed out: the attacker compromises the SSL/TLS process (obtains a "bad cert"), then uses a DNS-based attack which can be thwarted by DNSSEC. Cache poisoning (Dan Kaminsky style) can also be thwarted simply by adding entropy to the query and response (e.g. port randomisation) except when the attacker is a man in the middle -- which is why I chose that particular threat for the sake of illustration. So here's a dilemma for you: is our threat model a man in the middle? If it is, then DNSSEC is necessary to prevent tampering with DNS operation, but DNS tampering is not necessary for a man in the middle to conduct an attack (as I observed earlier), so DNSSEC is irrelevant to the security of the situation. If the threat is not a man in the middle, then DNSSEC isn't necessary for security, because simple non-cryptographic countermeasures will suffice. So, from a security perspective, DNSSEC is either irrelevant or unnecessary in your example: you choose.

The weakest link sans DNSSEC is not SSL/TLS, it's DNS cache poisoning. DNSSEC is exactly providing the additional security against this.

No, that's precisely wrong. Cache poisoning isn't a serious threat if SSL/TLS is working correctly. In the presence of functional SSL/TLS, DNS cache poisoning can only produce a denial of service attack. The scenario we're trying to prevent is, "A thinks he is talking with B, but is actually talking with C." Cache poisoning can give A the address of C instead of B, which is a start, but C can't pass himself off as B unless he compromises the SSL/TLS process. SSL/TLS provides end-to-end security. It catches DNS forgery. It catches route hijacking. It catches an arbitrary man in the middle. If SSL/TLS is working, every security compromise that DNSSEC can prevent has already been covered, and then some.

Not deploying software because it's new is not much of an argument - nothing would ever be implemented.

You've oversimplified my argument. Every bug is a potential security hole. Fresh code contains bugs that are only found through extensive testing and analysis, so new code tends to be less secure than mature code. From a security perspective, it's therefore sensible to prefer fixing old code over adding new code.

# 3 Reply | Link | Report Problems

Do you need SSL/TLS more than DNSSEC? James Galvin – Oct 11, 2009 3:58 AM

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 is incomplete and isn't fair to either SSL/TLS or DNSSEC. You seem to be suggesting that these technologies compete with each other and that just isn't true. They mitigate different threats, albeit in the case of MITM attacks they mitigate different classes of such attacks. Combining DNSSEC and SSL/TLS creates a whole that is stronger and better than either technology by itself. This does not make either more restrictive than the other nor does it make either more complex than the other. Just different. DNS is an infrastructure system. Virtually all applications and services depend on DNS to complete their function. Adding security to it provides a foundation that all applications and services can leverage to improve their security. DNSSEC is a significant step forward in improving the overall security of the Internet, in ways we can not even imagine yet. Similarly, SSL/TLS has shown that it can be the cornerstone of a set of security services for connection oriented applications and services, for example the web. However, as I'm sure you well know, the quality of the security is completely dependent on the ability of the end-user to judge the quality of the certification path. Browsers and other applications help this somewhat but do you really want to get into a discussion of user habits? Further, let's not forget about certificate revocation lists (CRLs), without which certificate quality is forever suspect in my opinion. DNSSEC has the advantage, as you point out, that the delegation path is tightly coupled with the signature chain. This feature was possible because of the infrastructure foundation that DNS represents. Certificates, more properly recognized as a public key infrastructures, have this same property (feature) within a closed system. The feature is not really lost, per se, in SSL/TLS, it's just more subjective because the naming infrastructure is not intrinsically related to the signature chain. If an end-user was more knowledgeable about certificate details and if applications that depend on certificates did a better job of helping the user work with certifcates and if a half-dozen other things, certificates would be better than they are. The closing statement in the article above is the most important point:

Using either is good, but using both will increase your security significantly, causing the least, um, exposure.

# 4 Reply | Link | Report Problems

The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet