Top of Mind: Problems with SSL, solved with DNSSEC?
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:
_443._tcp.www.example.com. 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 www.example.com. 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!