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:
weberjoh@jw-nb12-lx:~$ sudo apt-get install hash-slinger weberjoh@jw-nb12-lx:~$ tlsa --create --selector 1 --certificate host-dane.weberdns.de.crt host-dane.weberdns.de _443._tcp.host-dane.weberdns.de. IN TLSA 3 1 1 0d6fce3320315023ff499a3f3de1c362c88f8380311ac8c036890dab13243aa7
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:
_443._tcp.host-dane.weberdns.de. IN TLSA 3 1 1 0d6fce3320315023ff499a3f3de1c362c88f8380311ac8c036890dab13243aa7
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
_443._tcp. ...via DNS and can see that it is there authentic (AD flag):
weberjoh@jw-nb12-lx:~$ dig _443._tcp.host-dane.weberdns.de tlsa +dnssec +multi
; <<>> DiG 9.10.3-P4-Ubuntu <<>> _443._tcp.host-dane.weberdns.de tlsa +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59953
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_443._tcp.host-dane.weberdns.de. IN TLSA
;; ANSWER SECTION:
_443._tcp.host-dane.weberdns.de. 3066 IN TLSA 3 1 1 (
0D6FCE3320315023FF499A3F3DE1C362C88F8380311A
C8C036890DAB13243AA7 )
_443._tcp.host-dane.weberdns.de. 3066 IN RRSIG TLSA 8 5 3600 (
20160929094014 20160830084014 57909 weberdns.de.
aZgVX1C6uxACoNnPo4m36CRzMjfe2Gk7pciV2knGrb5P
Hbq1UV/u2EdFJD6v5Dhd4JAquuM7OW9CQVfE1f0g380/
HsUMzg6eZeOr3sMR2ERZXv4hut4sikdtjGhVmA6jSbfg
EQFM0BELYz/+Xzh9uJYoqzkbJ54uKCpapaWgELs= )
;; Query time: 1 msec
;; SERVER: 192.168.120.22#53(192.168.120.22)
;; WHEN: Tue Aug 30 11:50:16 CEST 2016
;; MSG SIZE rcvd: 278
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:
_443._tcp.host-dane.weberdns.de. IN TLSA 3 1 1 0d6fce3320315023ff499a3f3de1c362c88f8380311ac8c036890dab13243aa7 _443._tcp.host-dane-self.weberdns.de. IN TLSA 3 1 1 97b57e11a9f07976ae0a44b3d68179e61637f3ca43b719a149f8d524c0dc2405 _443._tcp.host-dane-self.weberdns.de. IN TLSA 3 1 2 bab6316ace46fdce7028ea0100c4c0c364dc2f092258f8958b9ab1bde89c73ade3bd37aebf54245268128b039114e760b6a0d79e366c8c0b396884ab4287a05a _25._tcp.mail.weberdns.de. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
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:
TLSA records found: 1 TLSA: 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 Connecting to IPv6 address: 2003:51:6012:110::15 port 25 recv: 220 mail.webertest.net ESMTP send: EHLO cheetara.huque.com recv: 250-mail.webertest.net recv: 250-8BITMIME recv: 250-SIZE 10485760 recv: 250 STARTTLS send: STARTTLS recv: 220 Go ahead with TLS TLSv1.2 handshake succeeded. Cipher: SSLv3 DHE-RSA-AES256-SHA Peer Certificate chain: 0 Subject CN: mail.webertest.net Issuer CN: StartCom Class 2 IV Server CA 1 Subject CN: StartCom Class 2 IV Server CA Issuer CN: StartCom Certification Authority SAN dNSName: mail.webertest.net DANE TLSA 3 0 1 [ae822a14fd5e...] matched EE certificate at depth 0 Validated Certificate chain: 0 Subject CN: mail.webertest.net Issuer CN: StartCom Class 2 IV Server CA SAN dNSName: mail.webertest.net Connecting to IPv4 address: 80.154.108.237 port 25 recv: 220 mail.webertest.net ESMTP send: EHLO cheetara.huque.com recv: 250-mail.webertest.net recv: 250-8BITMIME recv: 250-SIZE 10485760 recv: 250 STARTTLS send: STARTTLS recv: 220 Go ahead with TLS TLSv1.2 handshake succeeded. Cipher: SSLv3 DHE-RSA-AES256-SHA Peer Certificate chain: 0 Subject CN: mail.webertest.net Issuer CN: StartCom Class 2 IV Server CA 1 Subject CN: StartCom Class 2 IV Server CA Issuer CN: StartCom Certification Authority SAN dNSName: mail.webertest.net DANE TLSA 3 0 1 [ae822a14fd5e...] matched EE certificate at depth 0 Validated Certificate chain: 0 Subject CN: mail.webertest.net Issuer CN: StartCom Class 2 IV Server CA SAN dNSName: mail.webertest.net
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. 