Cisco Blogs

Top of Mind: Problems with SSL, solved with DNSSEC?

- October 5, 2011 - 3 Comments

Lately we have seen various attacks against the various SSL/TLS usages that we have in the world. The attacks have not been technical per se, but instead use weaknesses in the procedures that are used to get a certificate. Lets first look at how trust is built up using SSL.

A client is using a web browser, for example, and connects using SSL. During the handshake the server is presenting a certificate for the client, and part of the certificate is the key to use and some meta data. That meta information includes the domain name that is secured with the certificate (that is to be compared with the domain name in the URL) and a signature that guarantees that the certificate is correct. This signature is created by a certificate authority (CA) that has issued the certificate.

The CA exists because the client cannot trust every certificate that is out there, but instead each browser and operating system has a list of CAs that is trusted. The client is then calculating a so-called chain-of-trust from the certificate that is arriving in the SSL handshake to one of the trust anchors, which are CAs that are trusted because they are “installed” in the browser.

Everything relies on CAs issuing certificates for domains to the actual domain holder and not to someone else that, with the help of the certificate, can create a man-in-the-middle attack. Unfortunately with such a large number of CAs, it is sufficient that if only one makes mistakes or is hacked that suddenly any certificate can be issued for any domain. This is exactly what has happened a few times. Comodo and DigiNotar are two of the attacks that have happened lately and were reported by the press. But what we see in reality is that people continue to use the certificates. Although, DigiNotar was in removed from many trust lists as a CA, but still. Is the SSL mechanism as secure today as we think?

The Internet Engineering Task Force (IETF) has taken this seriously and geared up the work on the use of DNSSEC together with SSL. As readers might remember, DNSSEC is an add-on to DNS that adds digital signatures to the records in DNS. That implies one can know whether a signed response is the one that originated with the holder of the domain, and whether it has changed during transport (by a cache for example). As DNSSEC is now deployed (25% of all Top Level Domains (TLDs) in the world are now signed) we can use DNSSEC as a trusted mechanism to validate other “things.” There is, for example, support for DNSSEC validation of SSH certificates today, supported by OpenSSH.

But how is SSL connected with DNSSEC? That is discussed in the DNS based Authentication of Named Entities (DANE) working group within the IETF. In short, one takes a hash of the certificate, stores that hash in DNS, and signs it with DNSSEC. This DNSSEC-signed hash of the SSL certificate validates the certificate itself prior to calculating the normal chain of trust in the PKI (created by the certificates to the CA). This serves to insure that one does not change the way the chain of trust is calculated…at least for now. Maybe that should be done in the future? We’ll see.

If we go into a little bit more detail, one can have a look at what a TLSA resource record might look like: IN TLSA (
      0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
            7983a1d16e8a410e4561cb106618e971 )

Here we see a selector in the form of a prefix for TCP connections on port 443 to the domain name It has a usage field of 0, which implies “normal” PKIX validation must be done. A selector field that is also 0 implies it is a full certificate and a matching type field of 1 implies an SHA-256 hash of the selected content. Then the actual hash.

This TLSA record is stored in DNS, just like any DNS record, and is then signed. The client can then, after receiving the cert in the SSL/TLS handshake, calculate an SHA-256 hash and compare with the hash it received from DNS. This comparison allows the client to decide if the cert should be discarded or accepted before it does the normal PKIX validation.

This is yet another very interesting step forward that is made possible due to DNSSEC. So go home and sign your domains!

Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.

All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Industry-wide adoption is key, without it, DNSSEC will be another IPV6 :-) Also, Bruce Schneier said it best, you attack the flaws in implementation, not the actual technology itself.

    • You are correct in that we might end up with a catch-22 regarding DNSSEC just like IPv6. 25% of TLDs are signed, the root is signed but not more. Regarding the design, I am not the one that argues against Bruce Schneier ;-) but I claim still that the fact trust in SSL is designed in such a way that even if only one of the CAs do bad things, the whole system collapses. I think you should also look at this video from Black Hat USA that discusses the topic.

  2. Patrik, I agree with SSL, its a broken trust model. I am big fan of Moxie Marlinspike and his Trust Agility Model. (He released Convergence for this) and I am playing around with it on Firefox. Best, Ron @guerilla7 on twitter