Sender Reputation and Email Security – Part 5: DNS-based Authentication of Named Entities (DANE)
Securing the internet as a whole and electronic communication in particular is still based to a large extent on the use of so-called certificates. One example of this is transport encryption through Transport Layer Security (TLS): With the help of corresponding TLS certificates, web or email servers can be authenticated and the data exchange between them can be encrypted. This encryption ensures that data is transmitted in a tap-proof manner – provided that the certificates used are authenticated beyond doubt.
In the fifth part of our series on sender reputation, we explain how you can use DNS-based Authentication of Named Entities (DANE) to ensure the authenticity of certificates and protect your email traffic from access by criminals.
Potential for misuse even with TLS encryption
If you access the server www.nospamproxy.de, for example, this name must also appear in the TLS certificate. If, in addition, the certificate was issued by a trustworthy certification authority, you can be sure that you are connected to the right server. Unfortunately, it is precisely at this point that there is a certain potential for misuse.
Specifically, an attacker could redirect web or email traffic to a system he or she controls and also use a certificate with the corresponding name. For web servers, this danger is not very high any more because, on the one hand, browsers offer good protection against untrustworthy or even false certificates and, on the other hand, the trustworthy certification authorities do a good job.
However, this does not apply to server-to-server communication in the email sector. Certificates are hardly ever checked. It is not uncommon to even see certificates that have been expired for years in productive use. Thus, emails could be redirected to a compromised system via an encrypted channel.
What is DNS-based Authentication of Named Entities (DANE)?
DANE is a DNS-based network protocol that enables the cryptographic linking of certificates with DNS names when using TLS. With TLS, connections to a server are encrypted using TLS certificates, but the certificates themselves are not (securely) verified.
This is because a browser or email programme cannot recognise whether
- the retrieved certificate for the domain was actually created for the domain owner or
- a criminal has used DNS spoofing to impersonate the recipient and the email is redirected.
Why TLS is not secure without DANE
When you send an email with your email programme, it is delivered to the sending email server and sent to the receiving server. To ensure that the communication between these two servers is protected, you use TLS, i.e. transport encryption.
To find out whether the receiving server supports encryption using TLS and thus offers encryption, the sending server sends the STARTTLS command as plain text. This initiates the encryption. At this point, criminals have various possibilities to obtain the data contained in the email:
DNS spoofing
With so-called DNS spoofing, the attackers create a false IP address where the email is sent to. More precisely, fake DNS records are stored in the DNS resolver’s cache so that the name server returns a false IP address. As a result, the traffic is redirected to the attackers’ computer and then forwarded to the actual recipient after the data has been read, so that the attack remains undetected.
With the help of fake TLS certificates, this connection is encrypted which, however, makes no difference in this case. The email ends up in the hands of the attackers and can be decrypted by them.
Man-in-the-middle attack
In this type of attack, all connections from a specific email server are intercepted, for example by tapping into an internet hub. Here, too, the connection is encrypted with the help of a forged certificate and the respective email is then forwarded to the actual recipient.
Downgrade Attack
This form of attack works similarly to a man-in-the-middle attack, but the attacker claims not to support encryption. Since the vast majority of email servers send the email anyway, a certificate is not even required here. The email is transmitted unencrypted and later forwarded by the criminal to the actual recipient.
Emails are sent anyway if there is no TLS support on the recipient’s side, because some experts have agreed on the lowest common denominator for SMTP, so to speak, and act according to the motto “some encryption is better than no encryption”. With STARTTLS it is even more critical because it also allows the option “do not encrypt at all”.
This is different with TLS-based encryption of websites (HTTPS); in case of doubt, a window then opens that the user has to click away. However, email administrators hardly have the capacity to make this decision for hundreds or thousands of emails daily.
Problems when using TLS certificates
How is it that criminals can obtain and use forged certificates? The answer to this question lies in the way TLS certificates are created and authenticated:
It becomes clear that the assessment of the validity of TLS certificates depends on the trustworthiness of the issuing body. This is where DANE comes into play, which offers a simple and secure way to validate certificates and thus authenticate communication partners.
Authenticating TLS certificates with DANE
With DANE, certificates can be linked to entries in the domain name system (DNS) of the domain owner. The respective DNS communication is secured via DNSSEC so that it is ensured that the transmitted DNS responses can be verified. Without such protection, criminals could also forge these responses.
To use DANE, a TLSA record is stored in the DNS zone of the respective domain. This record contains a hash value that was formed from the certificate used, as well as further information on the interpretation of the TLSA record:
| Nummer | Wert | Bedeutung |
|---|---|---|
| 1: Certificate usage | 0 | PKIX-TA: Certificate Authority Constraint – Validation of the certificate by a defined Trust Anchor (trustworthy PKIX certification authority). The trust chain of the server certificate must be traced back to this trust anchor and pass the certificate check. |
| 1 | PKIX-EE: Service Certificate Constraint – Accept (trust) the server certificate referenced in the TLSA record if it was issued by a trusted PKIX certification authority. The certificate and trust chain must pass the trust verification. | |
| 2 | DANE-TA: Trust Anchor Assertion – Use of a defined trust anchor for the validation of the certificate. It does not have to be a PKIX certification authority that is trustworthy for the client. Trace the trust chain of the server certificate back to this trust anchor. | |
| 3 | DANE-EE: Domain Issued Certificate – Accept (trust) the certificate referenced in the TLSA record; no trust hierarchy check. | |
| 2: Selector | 0 | The full certificate is used. |
| 1 | Only the public key is used. | |
| 3: Matching type | 0 | Full certificate, no hash; generates very long DNS responses. |
| 1 | SHA-256 hash value | |
| 2 | SHA-512 hash value | |
| 4: Certificate association | – | The hash value of the certificate. |
Why DANE makes TLS encryption better
The mere fact that a TLSA record is present in the recipient’s DNS has considerable information value: it shows that the receiving server can and wants to encrypt. Attacks such as the downgrade attack mentioned above are thus ruled out, because the sending server accesses the DNS before sending the email and reads out the TLSA entry.
Even more crucial is that the hash value published in the DNS authenticates the respective certificate. If an attacker tries to redirect the email using a forged certificate, this cannot succeed: The sending server recognises that the hash value does not match the certificate and refuses to deliver the email.
Since the authentication of the certificates is realised completely via the TLSA entry, self-signed certificates can also be used for secure TLS-based encryption – signed certificates from official certification authorities are not mandatory. With Let’s Encrypt, there are now also free alternatives to fee-based offerings.
Check, set up and use DANE easily
As already mentioned, to use DANE you need to add a TLSA record to your DNS records. With the help of free generators, you can easily create a suitable TLSA record or check first whether a TLSA record already exists.
The use of DNSSEC is a mandatory requirement for securing web and email traffic using DANE. However, administrators often shy away from this effort. In recent years, however, the number of DNS providers with DNSSEC support has increased, so that this is no longer a real obstacle. Thus, DANE not only helps to improve email and web server security, but additionally increases security for the entire DNS traffic.
