- 03-08-21Wegwerkzaamheden BIT-2 van 16 aug tot en met 25 sep
- 23-07-21DDoS aanvallen naar BIT infra
- 25-06-21Mond- en neusmasker niet meer verplicht bij BIT
- 14-04-21Untangle haalt de complexiteit uit netwerkbeveiliging
- 03-03-21Vacature Netwerk Engineer
- 02-03-21Update RFO netwerk incident 17 februari 2021
- 18-02-21RFO netwerk incident
- 17-02-21Netwerk incident - www.bit.nl niet bereikbaar
- 22-01-21Avondklok: Datacenters 24/7 bereikbaar en remote hands en brains mogelijk
- 30-11-20Mond- en neusmasker vanaf 1 december bij BIT verplicht
Tips and tricks for DANE TLSA
At the end of 2016, we have already posted a blog on the DNS-based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol, TLSA in short. In this article we provide you with a few tips for its implementation.
TLSA is a protocol for safely publishing public keys and certificates that is based on DNSSEC. DNSSEC adds cryptographic verification to the DNS and thereby creates a reliable source for certificate properties. With DNSSEC, the Domain Name System has been made secure and false answers to questions to the DNS prevented. Certificates are used by, for example, websites that enabled HTTPS (TLS). These certificates are issued by certificate authorities which check, to various degrees, whether you are actually the owner/administrator of the domain name you are requesting a certificate for. However, there are more than 100 certificate authorities trusted by browsers. A problem with one of these authorities can result in the issue of false certificates for larger and smaller websites. Comodo and Diginotar, among others, have issued false certificates in the past. TLSA does not prevent the issue of false certificates, but limits the use.
The use of the DNS as a reliable source for certain information concerning a domain, is not new. Think about the publication of SPF and DKIM records in the DNS. TLSA ensures that the DNS, but only the safe variety (DNSSEC), becomes a reliable source for determining whether a website's certificate is false or not.
A TLSA-record consists of 5 components. The first part specifies the port number, the transport protocol and the host for which the certificate must be checked. This is done in the following format: _PORTNUMBER_TRANSPORTPROTOCOL_HOST, for example _443._tcp.www.bit.nl.
In a TLSA-record, there are several ways in which you can document the certificate authority for a certificate and/or which certificate is used exactly. See the RFC for an excellent explanation of the possibilities for the second part of the TLSA-record: the field for certificate use.
The third part, the selector, specifies which part of the certificate has to be checked. The matching type is part of component four and specifies how it should be checked. The last part is either the rough data or a hash of that data.
A full record would look something like this:
_443._tcp.www.bit.nl IN TLSA 3 0 1368BB5751B0382C8AAD4C58125997C21FE92 6D2349384DBBB063823D 34CD5945
The choices you make for the different components depends on the use of your certificate. If you use Let's Encrypt certificates with a short duration, you are going to want to include the certificate authority and not the exact certificate. However, if you do have automatic access to your DNS, you could include the exact certificate for short term certificates as well.
There is software available for creating a TLSA-record. OpenSSL can calculate the hash for you, but it is easier to use the tool provided by the NLNET Foundation: ldns-dane. Especially useful in automated processes and part of the Linux package ldnsutils. But there are more tools on the market. Another possibility is the online tool provided by Shumon Huque.
A website set up by SIDN Labs allows you to check whether you have a proper TLSA-record for your website. There are Nagios/Icinga plug-ins available for continuous monitoring whether your TLSA-record still matches your certificate. For clients with a monitoring service at BIT and configured TLSA-records, BIT can include the TLSA-record in the services that are to be monitored. We use the ldns-dane functionality for a self-written plug-in.
The browser's support on the field of TLSA is still somewhat behind. Through add-ons, for example cz.nic, this functionality can be added. The mail servers Postfix and Exim have an (experimental) built-in TLSA-support. Because DANE is independent of DNSSEC, we observe that the use of TLSA-records, especially in the Netherlands, where there are many DNSSEC enabled domains, is very often used, but still very limited. In November 2016 we have configured TLSA on our MX-servers, which resulted in a top-10 place for 'MX host providers by domain count'.
If you need help with implementing TLSA for your services, please feel free to contact us. We are happy to share our experiences if that benefits the internet.
By: Wido Potters