Difference between revisions of "DANE"

(Created page with "= How to set-up DANE for incoming email Email is being sent over the Internet with the SMTP protocol. SMTP is an opportunistic protocol. This means it is designed to fall back...")
(No difference)

Revision as of 11:16, 2 March 2022

= How to set-up DANE for incoming email Email is being sent over the Internet with the SMTP protocol. SMTP is an opportunistic protocol. This means it is designed to fall back to unencrypted data transfer if email servers for some reason cannot establish a secure connection.

The crucial difference between TLS for mail and TLS for the web (HTTPS) is that the use of `https' in a URL implies that TLS must be used and that a dedicated TCP port (number 443) is available for that purpose. By contrast, with mail there is currently no way to force the use of TLS.

In the IT industry there are a number of initiatives that aim to (at some point in the future) require TLS for SMTP.

One of these initiatives is MTA-STS which we covered in our blog https://blog.zimbra.com/2021/07/zimbra-skillz-enhance-email-confidentiality-using-mta-sts/

Another initiative is DANE a security protocol that adds additional verification of a TLS certificate. Compared to MTA-STS, DANE is more secure as it requires the use of DNSSEC, which means it can not be tampered with by attacking DNS transmissions. In addition DANE will provide additional verification of the TLS certificate used for encryption. This means that TLS communication can only work with the certificate that has been set-up via DANE. This way even when a rogue TLS certificate authority issues a certificate for your server, it can not be used to intercept your data.

DANE is completely implemented in Postfix and Zimbra whereas MTA-STS is currently only working for incoming email.

More background on email encryption and DANE can be found below in the further reading section.

In this article you will learn how to set-up DANE for Zimbra. The approach shown will work with Let’s Encrypt and other commercial certificates.

How to configure DANE for incoming email

The way DANE works is that you create a hash of your TLS certificate and publish this hash in DNS via a TLSA DNS record. Then clients and servers that implement DANE can verify that the TLS certificate used for the transmission is the same one that is published in DNS.

Certificate renewal or rollover

There are many different ways to implement DANE, but the most secure and practical way to do it is to use the 3 1 1 TLSA trust anchor to pin down the actual keys that your server certificate uses.

Then when you do a certificate renewal you can opt to not use a new private key. Basically you would use openssl to create a new Certificate Signing Request (CSR) and use the same private key. This makes it that you can continue to use the same 3 1 1 TLSA record. This is very practical if you renew your certificate frequently for example when you use Let’s Encrypt.

In case you use Let’s Encrypt you have to run certbot with the --reuse-key option. This way you can use the same TLSA record for a longer period of time. I will give the one-liner I use for reference, but you will have to do your own research to make it work for your use of certbot.

/usr/local/bin/certbot --manual --reuse-key --preferred-chain  "ISRG Root X1" --expand --manual-auth-hook /usr/local/sbin/hook.sh --manual-cleanup-hook /usr/local/sbin/cleanhook.sh --preferred-challenges dns -d "zimbra.tech" -d "*.zimbra.tech" certonly --manual-public-ip-logging-ok -n

I use manual-auth-hook and manual-cleanup-hook scripts to set the Let’s Encrypt DNS challenge in my DNS server, increment the DNS zone serial and trigger a DNSSEC signing of the zone. You may not need this, more information on this in the Let’s Encrypt documentation: https://eff-certbot.readthedocs.io/en/stable/using.html#pre-and-post-validation-hooks

Of course in cryptography all keys have a shelf life, and it is a good practice to rotate the certificate keys after a while. In the further reading section you can find a link that tells you what to do if you want to do a roll-over with a new TLSA record.

Generating a TLSA record

To generate the TLSA record you can create the following bash script. Change mail.zimbra.tech with the domain name of your mail server. And /etc/letsencrypt/live/zimbra.tech/cert.pem with the path to your certificate.


echo "zimbra.tech"
printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \
        mail.zimbra.tech \
        $(openssl x509 -in /etc/letsencrypt/live/zimbra.tech/cert.pem -noout -pubkey |
            openssl pkey -pubin -outform DER |
            openssl dgst -sha256 -binary |
            hexdump -ve '/1 "%02x"')

The output would be:

_25._tcp.mail.zimbra.tech. IN TLSA 3 1 1 9fe61e181ec3e2b4f451fa6c679e3c50c47f53ad40f90bfe6bf7312609a32948

If you use a Bind DNS server you have to copy/paste this entire line into your zone file. Here is an example how it looks on Direct Admin:

image A TLSA 3 0 1 record in Direct Admin.

Test your incoming DANE

Go to https://internet.nl/ and type your email domain in the email test and click Start test.

image DANE test.

image 100% test result.

You can scroll down on the test results page and see details of all the tests performed, the last test checks for DANE existence and validity.

image DANE test result.

See also: https://wiki.zimbra.com/wiki/Cipher_suites

How to configure DANE for outgoing email

This was covered in our blog post: https://blog.zimbra.com/2022/03/zimbra-skillz-enable-dane-verification-for-outgoing-email-in-zimbra/

Further reading

Jump to: navigation, search