Packetizer

DNSSEC Paves the Way for Better TLS Security

August 20, 2012

Everyone is familiar with the padlock that appears on the address bar in the web browser indicating that the communication session is secure. However, few people understand the technology behind that padlock, namely the Transport Layer Security protocol (TLS), or what a digital certificate is. It is those digital certificates that is the subject of this blog post.

For years, a small group of companies have served in the capacity of Certificate Authorities (CAs). The companies, along with makes of web browser, form the Certificate Authority / Browser Forum. It’s a fairly exclusive club, really. They purposely limit the number of certificate authorities so as to ensure that the price people pay for digital certificates is at a price that allows them to make money. Oh, and of course, to provide “trust” in some way. Gaining membership into this exclusive club is hard. Suppose you want to establish a new business to be a root certificate authority. In order to do that, you must “actively issue certificates to Web servers that are openly accessible from the Internet using any one of the mainstream browsers”, as in you must be in the business already. It’s a bit of a chicken and egg problem. One cannot actively issue certificates if the web browser makers do not “trust” you and you cannot gain their trust unless you are a root certificate authority.

Not only is the CA/Browser Forum mostly a club that tightly controls who can trust whom on the Internet, largely for the financial benefit of the members of the Forum, the whole system is, in fact, flawed. If you visit a web site that claims it is secure, can you really trust the certificate presented? The fact is, there has been more than one casewhere a digital certificate was issued by a certificate authority in error. How can this happen? It’s possible because, until recently, DNS has had no security applied in practice, for one. Second, people are able to get into corporate email accounts. Anyone can create create a public/private key pair for the certificate. A hacker just needs to trick a certificate authority into signing it. Usually, this requires only that the person verify that they own an email address at the domain, usually one of the few the certificate authority believes to be an administrative address.

Now that DNSSEC is here, a better way exists to secure browser communication or other communication that utilizes TLS. Rather than create a certificate and have it signed by a certificate authority, a domain owner can create a certificate and place a signature of that certificate into the domain’s DNS. Since all DNS records are signed by the domain owner and DS records created by the domain owner are inserted into the registrar’s DNS servers, it is possible to trust those records. RFC 6698 defines precisely how to do that. Essentially, one creates a self-signed certificate and inserts a signature of that certificate in DNS as a TLSA record. For example, suppose one creates a certificate for www.example.com on port 443 (standard TLS port) and wishes that to be trusted by browsers. One would create a signature of that certificate and insert a TLSA record like this:

_443._tcp.www.example.com. IN TLSA 1 1 \
    C3E2885170FB937E45FCE92CCEE01904A3EE3248156FCD7B945F38994A1F9496

It will take a few years before browsers and other TLS clients start using DNSSEC and TLSA records, but the technology now exists. This is significantly more secure than today’s certificates, since domain owners are in complete control of certificates. No longer is there a risk of a certificate authority issuing a bogus certificate. Domain owners can easily cancel certificates by simply removing the associated TLSA records in DNS.

Click here to view the main blog page.

Paul E. Jones

About Me
My Blog ATOM Feed
Email Me
IM Me

Certified ScrumMaster®