DNS-based Authentication of Named Entities (DANE) is a great feature that uses the advantages of a DNSSEC signed zone in order to tell the client which TLS certificate he has to expect when connecting to a secure destination over HTTPS or SMTPS. Via a secure channel (DNSSEC) the client can request the public key of the server. This means, that a Man-in-the-Middle attack (MITM) with a spoofed certificate would be exposed directly, i.e., is not possible anymore. Furthermore, the trust to certificate authorities (CAs) is not needed anymore.
In this blog post I will show how to use DANE and its DNS records within an authoritative DNS server to provide enhanced security features for the public.
In my last posts I covered a secure installation of BIND as an authoritative DNS server, as well as the implementation of DNSSEC. This is really mandatory because without a signed DNS zone DANE would be useless. Though I am using BIND for the examples below, DANE can be used with any other DNS server, too.
What’s DANE?
The abstract of RFC 6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA”, in which DANE is proposed, describes pretty good what DANE is: “Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain’s TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software.”
Today, a browser establishes a secure TLS connection to a known server (DNS name) with an “unkown” certificate (not proved by the end user). We are relying to certificate authorities (CAs), which once verified the certificate to be owned by the server operator. Unluckily, any (!) CA is able to sign every (!) certificate in the world, even if a certificate is NOT owned by the server itself, but by a malicious third party that wants to intercept the secure communication via a man-in-the-middle (MITM) attack.
With the new DNS resource record “TLSA”, the hashed public key is publicized within the DNS server of the same authority/entity that owns the TLS server, e.g., an HTTPS server or an SMTPS mail gateway. Now, an end user client can really validate that the server TLS certificate is owned by the same organization which owns the DNSSEC server. Hence, MITM attacks with spoofed certificates are not possible anymore.
For more information about DANE, refer to the RFCs: 6698, 7218, 7671, and 7672.
Generate TLSA Records
No changes must be made by the TLS servers. The only thing to do is to place the hashed public key into the DNS zone. For the most common scenarios, the fields within the TLSA record are the following (refer to RFC 7671, section 5.1):
Usage: 3 – DANE-EE: Domain Issued Certificate
Selector: 1 – SPKI: Use subject public key
Matching-Type: 1 – SHA-256
For an on-site generation of TLSA records the tool “tlsa” out of the “hash-slinger” toolkit can be used. On a Ubuntu server this works as follows:
An easy to use online tool by Shumon Huque is here: Generate TLSA Record. Copy and paste your certificate, etc., and choose the selector field of “0 – Cert”:
In any way, the TLSA resource record for my test domain “host-dane.weberdns.de” is this:
This string must be placed into the appropriate zone file on the DNSSEC signing server, in my case “weberdns.de”. After then, I can manually test/request the TLSA record
via DNS and can see that it is there authentic (AD flag):
Examples
I generated three different TLSA records for my test domains (IPv6-only):
host-dane.weberdns.de <- with a trusted CA signed certificate
host-dane-self.weberdns.de <- with a self-signed (!) certificate
mail.weberdns.de <- with a CA signed certificate whose FQDN is NOT mail.weberdns.de
The appropriate TLSA records are the following. Note that I have some different usage and matching type fields, e.g., SHA256 and SHA512:
Note that in all three cases a TLSA check is valid though only the first TLS certificate is correctly signed by a trusted CA with its correct common name! This is the main advantage of DANE, that self-signed certificates can be used, even with incorrect names, as long as the certificate itself is the correct one published in the DNS.
Online Tools
There are great online tools for checking TLSA records either for HTTPS or for SMTPS:
Verify a DANE TLSA Record by SIDN Labs <- for HTTPS
Check a DANE TLS Service by Shumon Huque <- for many protocols, incl. SMTPS w/ STARTTLS
DANE SMTP Validator by sys4 <- SMTPS
DANE Validator by DANEtools <- for many protocols but buggy
Here a two sample screenshots out of the tools for my test domains. The “host-dane-self” domain is valid though self-signed, while the “mail.weberdns.de” is valid, too, though not congruent with the name of the certificate:
A more detailed view is the text output from Shumon’s SMTPS test with STARTTLS. It greatly shows the connection (via IPv4 and IPv6), the common name of the cert, as well as the matching TLSA record:
And by the way, for more information about DANE, have a look at the resources from “sys4”. They offer a DANE mailing list as well as a common mistakes help page.
Browser Add-On: DNSSEC/TLSA Validator
The only good browser plugin for checking DNSSEC and DANE records is the “DNSSEC/TLSA Validator“. Unluckily it is not updated since almost two years (as of October 2016) and I ran into some Firefox errors while this plugin was enabled.
However, for some tests it shows the status of the DNS name (first green icon) as well as the DANE/TLSA status (second green icon):
Problem: SSL Interception
One problem will arise if browsers do their own DANE check (which is unluckily not happening today) while organizations are using SSL/TLS interception at their firewalls/proxies. In these cases, the SSL man-in-the-middle “attack” will spoof the certificate to an own created one which is signed by the organizations CA. Though this CA is installed in the browsers, the TLSA check will fail. To my mind, the only way to accomplish this (while not stopping the MITM) is the creation of an “Island of Trust” for DNSSEC with real-time TLSA record spoofing. (Any other ideas?)
Conclusion
That was easy! With only some little DNS resource records, much more security, i.e., authentication, can be achieved. Browsers can access self-signed websites without relying on (malicious) CAs, and MTAs (mail transfer agents) can send mails with the usage of TLS directly to the correct (authentic) destinations.
Today (2016), we are still stuck in the chicken-or-egg problem: Only some sites have DNSSEC signed TLSA records while only some end systems (browsers, MTAs) can validate them. To overcome this problem: Start signing you DNS zones now and insert as many TLSA records as you can. <img src="https://s.w.org/images/core/emoji/2/72x72/1f609.png" alt="