EN 
05.11.2024 Miriam WELCOME IN MY WORLD

This website is originally written in the Czech language. Only part of the content is machine (AI) translated into English. The translation may not be exact and may contain errors.

Tento článek si můžete zobrazit v originální české verzi. You can view this article in the original Czech version.
Zabezpečení SMTP komunikace pomocí DANE

Securing SMTP communication using DANE

Edited 16.05.2022 15:15 | created | Petr Bouška - Samuraj |
When sending messages using SMTP between mail servers, TLS encryption is already heavily used. By default, mail servers do not check the validity of the certificate used. The indication that they support encryption is sent in clear text in the protocol. DNS-based Authentication of Named Entities can be used for security. We publish a special TLSA record in DNS that says that a particular service supports encryption and what certificate it uses.
displayed: 7 533x (7 447 CZ, 86 EN) | Comments [1]

DNS-based Authentication of Named Entities (DANE)

SMTP Communication Encryption

Communication encryption between mail (SMTP) servers (MTA - Message Transfer Agent) is important for protection against Man-in-the-middle attacks. For the text protocol SMTP, we can use the STARTTLS extension. More in SMTP over TLS encryption on MS Exchange and Cisco Email Security.

This doesn't protect the communication if an attacker can modify it along the way. For example, they can remove information about STARTTLS support, so encryption doesn't start (STARTTLS Downgrade Attack). Or they can forge their certificate and redirect traffic to their server. An SMTP server typically doesn't check the validity of the certificate or the domain used.

Not all SMTP servers support connection encryption, so if we turn on STARTTLS requirement, we might lose some messages. The situation is improving. Our statistics for the last month show that 91.5% of incoming connections and 98.2% of outgoing connections are encrypted.

DANE Principle

The solution is to use DNS-based Authentication of Named Entities (DANE), which informs the other party using a DNS record. That our mail server supports STARTTLS and what certificate it uses or from which CA. The condition is that the records in the domain are signed using DNSSEC - Domain Name System Security Extensions, so the DNS record cannot be forged.

When establishing an SMTP connection, it's verified whether a TLSA record exists for the domain. If so, the other side must indicate STARTTLS support and use the certificate specified in the TLSA record for encryption. If the conditions are not met, the connection is not established.

DANE is described in several RFCs, mainly RFC 6698 (RFC 7218 adds abbreviations) and for SMTP RFC 7672. A general description can be found, for example, in DANE for SMTP how-to.

To implement DANE, we must first create the corresponding TLSA record or records (for MX domain names). Then enable DANE verification on the sending mail servers (gateway). We must also have TLS enabled. With DANE enabled, there's no problem if the target mail server (domain) doesn't support DANE. It works standard using STARTTLS or plain text.

Note: DANE can also be used with other protocols, such as HTTPS. It could thus solve the trusted use of a certificate from an untrusted authority.

TLSA Record

DANE adds a new type of record (Resource Record) TLSA (Transport Layer Security Association, type 52) to DNS. The domain name of the record is composed of port, protocol, and FQDN _<port>._<ipprotocol>.<domain>. So for an SMTP server running at address mail.company.com, the record is _25._tcp.mail.company.com.

We create a TLSA record for each server (existing MX record on the domain). Records are created on the MX domain. So if the mail server has an address on a different domain than the domain we receive mail for, we must create a record here. The domain must be signed using DNSSEC.

The TLSA record contains four items in the RDATA part:

  • Certificate Usage - determines how (which) to verify the certificate
    • 0 - CA certificate from which the service has its certificate, the certification path must be valid, we must trust the root certificate (PKIX-TA: CA constraint)
    • 1 - service certificate (EE - End Entity), the certification path must be valid, we must trust the root certificate (PKIX-EE: Service certificate constraint)
    • 2 - CA certificate that verifies the service certificate, doesn't need to be trustworthy, we can use for our own CA (DANE-TA: Trust Anchor Assertion)
    • 3 - service certificate (EE - End Entity), which is self-signed, the trustworthiness of the authority is not verified (DANE-EE: Domain issued certificate)
  • Selector - determines which part of the certificate is verified with the specified data (Certificate Association Data)
    • 0 - entire certificate (Cert)
    • 1 - only the public key of the certificate, which is usually sufficient (SPKI)
  • Matching Type - determines what data is used for comparison (Certificate Association Data)
    • 0 - entire content (exact match) (Full)
    • 1 - SHA-256 hash (SHA-256)
    • 2 - SHA-512 hash (SHA-512)
  • Certificate Association Data - the actual binary data that is compared according to the specified settings with the provided certificate

RFC 7672 - DANE Authentication recommends using only certain variants of the first three items for SMTP and explains why.

Primarily, it's the variant DANE-EE(3) SPKI(1) SHA2-256(1). This means we take the public key of the certificate used on the mail server, and calculate the SHA-256 hash from it, which we store in Certificate Association Data. During verification, the public key sent for establishing TLS is taken, its SHA-256 hash is calculated and compared with the value in the TLSA record. It doesn't check whether the certificate is issued by a trusted authority.

Alternatively, we can add as a backup DANE-TA(2) Cert(0) SHA2-256(1) (in practice, DANE-TA(2) SPKI(1) SHA2-256(1) is more commonly used).

Example of a record

_25._tcp.mail.nic.cz. 1800 IN TLSA 3 1 1 4F9736249AB586F37FC110856F6A3358ADADBF99DB03628866466194F5BB2E09

We can use the authority's certificate in the TLSA record, so if we change the certificate from the same CA, we don't have to change the record. Even if we use the end certificate, the public key may not change when the subsequent one is issued. If we need to replace the record, a second record is created, both exist for the duration of TTL, and then the older one is deleted. TTL for the TLSA record should not be greater than 1 hour (3600 seconds).

To create a TLSA record, we can use the TLSA Record Generator. The Usage option only determines the item in the TLSA record, but the hash (or binary value) is calculated from the inserted certificate in Base-64 encoded X.509 format. If we want to use the CA certificate (Usage 0 or 2), we must insert that one.

Microsoft DNS Server and TLSA

The DNS Server role of Windows Server supports the TLSA record since Windows Server 2016 (it also adds support for unknown records, so we can create a record type that the DNS server doesn't know, using binary format). It's mentioned in What's New in DNS Server in Windows Server.

However, we can't create the record using the DNS Manager GUI, but only with the PowerShell cmdlet Add-DnsServerResourceRecord.

Example of creating a TLSA record

Add-DnsServerResourceRecord -TLSA -CertificateUsage DomainIssuedCertificate -MatchingType Sha256Hash -Selector SubjectPublicKeyInfo -CertificateAssociationData "99b38700b469e1379e18788ea9f91307823142265d7294ab4fd1e9a7383d3316" -ZoneName company.com -Name _25._tcp.mail
Add-DnsServerResourceRecord -TLSA -CertificateUsage TrustAnchorAssertion -MatchingType Sha256Hash -Selector SubjectPublicKeyInfo -CertificateAssociationData "e3c8573709f795a240cacac8069ace72ec146f4f7b04634bedef8c54ced1722b" -ZoneName company.com -Name _25._tcp.mail

Displaying the record

Get-DnsServerResourceRecord -ZoneName company.com -Name _25._tcp.mail -RRType TLSA
$r = Get-DnsServerResourceRecord -ZoneName company.com -Name _25._tcp.mail -RRType TLSA
$r.RecordData | select *

Testing DANE and Domain Reports

We can use various online tools to test whether our mail domain properly supports DANE.

  • My Email Communications Security Assessment - we enter an email address to which a message arrives (if it's not blocked by the AntiSpam filter). We reply to the message, we don't need to write anything, but the subject must be preserved. A report is created, whose ID arrives in the email.
  • Internet.nl - just enter the email domain and we can more extensively test the security of email communication
  • Huque.COM - contains various tools and a TLSA generator, for example Check a DANE SMTP Service

RFC 8460 describes SMTP TLS Reporting (TLS-RPT). Similar to DMARC, a special DNS TXT record is created with the address where reports should be sent. Various online services can display reports for us, for example DMARCian - What is SMTP TLS Reporting?.

Cisco Email Security (ESA)

The Cisco Email Security gateway supports DANE verification. Description Cisco ESA - DNS-based Authentication of Named Entities, DANE for Email Security Appliance.

Enabling DANE support for sending mail

  • Mail Policies - Destination Controls

The settings are made in the same place where we enabled TLS for sending mail. We edit or create a profile for the target domain or we can use Default for all. TLS must be enabled to set up DANE. We must also use a DNSSEC capable DNS Resolver (if we have Root servers set up, it is fine). In the DANE Support item, we select

  • None - DANE disabled
  • Opportunistic - if the remote side does not support DANE, opportunistic TLS (STARTTLS or unencrypted connection) is used, if DANE is supported, it is used
  • Mandatory - DANE is mandatory, if the remote side does not support it, the connection is not established

Monitoring and controls

  • Monitor - TLS Connections

For outgoing connections, we see statistics on encryption usage and also DANE Success and DANE Failure. In the details, we have data for individual domains. However, DANE Failure is apparently counted even for messages where the domain does not support DANE (which I do not think is correct) and the overall values in the table seem strange to me. I have not found any explanation of the individual items.

  • Monitor - Message Tracking

Message search in the log allows under Advanced to select the event DANE Failure. In the details, we see the message if DANE failed (nothing is here in case of success). Example of two errors:

MID 5290305 (DCID 0) DANE failed for cisco.com. Reason: A record INSECURE.
MID 5262944 (DCID 664172) DANE failed for seznam.cz. Reason: No TLSA Record. 
  • System Administration - Log Subscriptions

For even more detailed information, we can download and view mail_logs.

DANE Failure

As I mentioned, it seems to me that in TLS Connections there are strange values for DANE Failure. I have under 5% DANE Success and similar DANE Failure (around 48%) and Successful - Preferred (around 47%). It seems to me that mostly both DANE Failure and Successful - Preferred are counted.

In Message Tracking, it seems to me that only cases of DANE Success have no DANE information in the log. All others log DANE failed once, but the message is immediately delivered.

Message 5618574 queued for delivery.
MID 5618574 (DCID 876522) DANE failed for seznam.cz. Reason: No TLSA Record.
Delivery connection (DCID 876522) successfully accepted TLS protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384 None.

In practice, there are cases where the target server temporarily does not accept messages. At that moment, DANE failed is repeatedly logged and an email alert is sent to the administrator (if set) DANE verification failed.

If we filter the event DANE Failure in Message Tracking, it looks like almost all outgoing messages are offered. When we look into mail_logs, we see that after the error, it falls back to normal TLS.

MID 5520505 DCID 818685 DANE failed for the domain seznam.cz: No TLSA Record
DANE fall back for seznam.cz in the Opportunistic mode

I created a ticket for this situation with Cisco TAC support. The technician quickly acknowledged that it was a bug and created bug CSCwa01524. Hopefully, it will be fixed.

Verifying DANE for a domain in ESA CLI

Using the CLI, we can perform a comprehensive verification that a certain domain supports DANE and the connection is fine. We also verify (by querying a known domain) that our DNS settings are correct (supports DNSSEC).

ESA.firma.cz> daneverify ietf.org

SECURE MX record(mail.ietf.org) found for ietf.org
SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
Connecting to 4.31.198.44 on port 25.
Connected to 4.31.198.44 from interface 192.168.1.1.
SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
Checking TLS connection.
TLS connection established: protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384.
Certificate verification successful
TLS connection succeeded ietf.org.
DANE SUCCESS for ietf.org
DANE verification completed.

If we use a DNS server that does not support DNSSEC, it should be displayed.

ESA.firma.cz> daneverify ietf.org

BOGUS MX record found for ietf.org
DANE FAILED for ietf.org
DANE verification completed.

Example if the domain is not signed or has not published a TLSA record.

ESA.firma.cz> daneverify cisco.com

INSECURE MX record(alln-mx-01.cisco.com) found for cisco.com
INSECURE MX record(alln-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (173.37.147.230) found for MX(alln-mx-01.cisco.com) in cisco.com
Trying next MX record in cisco.com
INSECURE MX record(rcdn-mx-01.cisco.com) found for cisco.com
INSECURE MX record(rcdn-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (72.163.7.166) found for MX(rcdn-mx-01.cisco.com) in cisco.com
Trying next MX record in cisco.com
INSECURE MX record(aer-mx-01.cisco.com) found for cisco.com
INSECURE MX record(aer-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (173.38.212.150) found for MX(aer-mx-01.cisco.com) in cisco.com
DANE FAILED for cisco.com
DANE verification completed.

ESA.firma.cz> daneverify seznam.cz

SECURE MX record(mx1.seznam.cz) found for seznam.cz
SECURE A record (77.75.78.42) found for MX(mx1.seznam.cz) in seznam.cz
Connecting to 77.75.78.42 on port 25.
Connected to 77.75.78.42 from interface 192.168.50.50.
No TLSA record found for MX(mx1.seznam.cz) in seznam.cz
Trying next A record (77.75.76.42) for MX(mx1.seznam.cz) in seznam.cz
SECURE A record (77.75.76.42) found for MX(mx1.seznam.cz) in seznam.cz
Connecting to 77.75.76.42 on port 25.
Connected to 77.75.76.42 from interface 192.168.50.50.
No TLSA record found for MX(mx1.seznam.cz) in seznam.cz
Trying next MX record in seznam.cz
SECURE MX record(mx2.seznam.cz) found for seznam.cz
SECURE A record (77.75.76.32) found for MX(mx2.seznam.cz) in seznam.cz
Connecting to 77.75.76.32 on port 25.
Connected to 77.75.76.32 from interface 192.168.50.50.
No TLSA record found for MX(mx2.seznam.cz) in seznam.cz
Trying next A record (77.75.78.32) for MX(mx2.seznam.cz) in seznam.cz
SECURE A record (77.75.78.32) found for MX(mx2.seznam.cz) in seznam.cz
Connecting to 77.75.78.32 on port 25.
Connected to 77.75.78.32 from interface 192.168.50.50.
No TLSA record found for MX(mx2.seznam.cz) in seznam.cz
DANE FAILED for seznam.cz
DANE verification completed.
Author:

Related articles:

Electronic mail - email

SMTP protocol and its features. Protection of electronic mail against SPAM and Phishing. Encryption of mail...

Computer networks

This series covers the basics of computer networking. Important practical aspects that everyone interested in networking should know are briefly described. It contains some of the most widely read articles on this site. It is used for teaching in schools.

If you want write something about this article use comments.

Comments
  1. [1] Cejvik(zavinac)sezam.cz

    Hezký den, nmašel jsem doménu kde DANE funguje: nukib.cz tak ten příklad daneverify by bylo fajn obohatit taky o záznam kde bude výsledek SUCCESFULL. Možná se zeptám blbě, ale když tedy podle toho návodu udělám TLSA záznam u WEDOSu na svou doménu neco.eu nebo neco.cz s tím, že tam dam SHA256 otisk certifikátu email.seznam.cz? Ten se aůe mění každé 3 měsíce a to se mi nechce :-/

    Wednesday, 22.06.2022 14:51 | answer
Add comment

Insert tag: strong em link

Help:
  • maximum length of comment is 2000 characters
  • HTML tags are not allowed (they will be removed), you can use only the special tags listed above the input field
  • new line (ENTER) ends paragraph and start new one
  • when you respond to a comment, put the original comment number in squar brackets at the beginning of the paragraph (line)