SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
Use DANE to start and verify secure SMTP connections between MTAs (or MUA-to-MTA submission). This mitigates a MITM-attack.
👉 DANE for email you receive = publishing a DNS record.
- Your mail server has support for DANE.
👉 DANE for email you send = configuring your mailserver.
DANE first looks up the TLSA-records in the DNS. When one or more valid records are found: The mailserver will start a TLS connection. Opening that connection returns a certificate. That certificate must match one of those TLSA-records.
The FQDN in the MX-record is used to connect with TLS on TCP port 25.
With a TLSA record in your DNS; A server that wants to send to you can verify the certificate that it receives.
👉 You probably want to use: DANE-EE(3), SPKI(1), SHA-256(1):
_25._tcp.server.example.com. 300 IN TLSA 3 1 1 <your SHA2-256 hash>
Replace the value of <your SHA2-256 hash> with the hashed value of your own certificate.
Replace server.example.com with your own (sub)domain.
- Mailservers on the same domain (one.server.com, two.server.com) need a TLSA record for each of their subdomains.
- Mailservers on a different domain (mailserver.com, backup-server.com) both need a TLSA record in their own zone.
- Beware of servers that use SNI: Add two TLSA-records when the server in the MX-record is not using the default certificate.
The DNS-record consists of the following 4 fields:
PKIX-TA(0)PKIX-EE(1)DANE-TA(2)Trust Anchor — Root or Intermediate CertificateDANE-EE(3)End Entity Certificate
Do NOT use PKIX-TA(0) and PKIX-EE(1). Postfix discards those records. Exim seems to support PKIX but there is no added security when an application supports all four certificate usages. You only need more DNS-records and possibly run into the issue of a mail server (sending to you) not having that root or intermediate.
The use of a public authority e.g: "Let's Encrypt" with DANE-TA(2) records opens you up to various risks of certificate mis-issuance, because Let's Encrypt operates on a TOFU (trust on first use) model, with rather weak proofs of domain control. Some users are willing to accept this risk for the convenience of using Let's Encrypt, enabling a single certificate to support both MTA-to-MTA SMTP and MUA-to-MTA submission, ... Others prefer to avoid the security risks. Google have their own dedicated intermediate CA, they can use a DANE-TA(2) record for that CA without much risk. A company with a corporate account with a CA and managed enrollment (no TOFU) might do likewise.
— by Viktor Dukhovni (May 03, 2022)
👉 Prefer DANE-EE(3). Consider DANE-TA(2) when you are that Root or Intermediate.
Cert(0)Full CertificateSPKI(1)Subject Public Key Info
TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of "Cert(0)". Otherwise SPKI(1) is recommended because it is compatible with raw public keys [RFC7250] and the resulting TLSA record needs no change across certificate renewals when issued with the same key.
👉 Use SPKI(1) with DANE-EE(3). Use Cert(0) with DANE-TA(2).
Full(0)SHA-256(1)SHA2-256 hashSHA-512(2)SHA2-512 hash
Always use SHA-256(1). Do NOT use type Full(0). In the future you want to use both of these hashes. When SHA2-512 (and any upcoming algorithms) become mandatory for applications to implement (as defined in future RFCs). Then you would be using those mandatory algorithm(s) only.
👉 Use SHA-256 for now. Care about SHA-512 later.
Contains the value of the Certificate or Public Key. In this case the SHA2-256 hash of the Cert(0) or SPKI(1).
$ dig +short MX "example.com"As an example we state that the command above returns the following result:
10 your-mail-server.com.
11 your-backup-mail-server.com.
In this case you want to run the openssl commands (explained below) to verify the certificates you receive (for both of these servers). Then you want to add a TLSA record for each of these servers in their own zone.
$ openssl s_client -connect "your-mail-server.com:25" -starttls smtp </dev/nullThe command above prints the certificate that is being used. When using DANE-TA(2) you need to make sure that you send that Trust Anchor as well (you would be sending the full chain in stead of a single certificate). Otherwise there is no value (cfr. certificate) to compare. Therefor verification will never pass.
$ openssl s_client -connect "your-mail-server.com:25" -starttls smtp -servername "mail.example.com" </dev/nullWhen the certificate is different in the two commands above: Make sure you add a TLSA record for both certificates. Servers that do not support SNI will receive the certificate from the first openssl command (because it is the fallback certificate).
Prefer using the hostname of the IPv4 (the reverse DNS). In this case all servers (with or without SNI) should receive the same certificate. You can verify this by running the two openssl commands above. In this case they must return the same certificate.
In the openssl commands above: Most cases will return a single certificate. That would be your
End Entitycertificate (DANE-EE). You want to manually verify that the certificate you received is the same as the one you are using on your server.
echo $(openssl x509 -in "/path/to/cert.pem" -noout -pubkey \
| openssl pkey -pubin -outform DER \
| openssl sha256 -binary \
| hexdump -ve '/1 "%02x"')In the command above, replace /path/to/cert.pem with the location of your servers end certificate.
Generate the SHA2-256 hash based on the Full Certificate:
DANE-TA(2) should use the "Full certificate(0)" selector in stead of the "SPKI(1)". Such TLSA records are associated with the whole trust anchor certificate, not just with the trust anchor public key. Otherwise this may, for example, allow a subsidiary CA to issue a chain that violates the trust anchor's path length or name constraints.
echo $(openssl x509 -in "/path/to/ca.pem" -outform DER \
| openssl sha256 -binary \
| hexdump -ve '/1 "%02x"')In the command above, replace /path/to/ca.pem with the location of your root or intermediate certificate.
The recommended: DANE-EE(3) with SPKI(1) and SHA256(1) would result in a DNS-record e.g:
_25._tcp.your-mail-server.com. IN TLSA 3 1 1 <sha256-hash>
And optionally a DNS-record for the backup server:
_25._tcp.your-backup-mail-server.com. IN TLSA 3 1 1 <sha256-hash>
DANE-TA(2) with FullCert(0) and SHA256(1) would result in a DNS-record:
_25._tcp.your-mail-server.com. IN TLSA 2 0 1 <sha256-hash>
DANE-TA(2) with Digest Algorithm Agility would result in two DNS-records:
_25._tcp.your-mail-server.com. IN TLSA 2 0 1 <sha256-hash>
_25._tcp.your-mail-server.com. IN TLSA 2 0 2 <sha512-hash>
Consider the use of Digest Algorithm Agility when SHA2-256 becomes weak.
Email that you send, will search for the TLSA records of the receivers MX-domain. When a record is found, your server will start a TLS connection and verify the certificate it receives.
$ bash validate-dane-tlsa.sh "example.com"$ bash dane-tlsa.sh "/path/to/cert.pem"https://datatracker.ietf.org/doc/html/rfc7671#section-8.1
Sources: