DANE to secure SMTP exchanges

Computer messages are exchanged between servers mainly via SMTP (Simple Mail Transfer Protocol). This protocol is not natively secure, which opens up the possibility for an intermediary to intercept and spy on these communications.

To secure these flows, you can use TLS (Transport Layer Security), a protocol that enables the encryption of exchanges. Unfortunately, there is nothing in SMTP communication to inform the sending server’s encryption capability. The widely deployed solution to this problem is to use encryption opportunistic(StartTLS). After an initial, unencrypted communication, it can be used, inform each server of its respective encryption capabilities and thus select the best compatible algorithm for the rest of the communication.

The diagram below explains how it works and the steps involved. secure SMTP communication under StartTLS when sending an email from user “from@exp.fr” to “to@dest.fr”.

The use of opportunistic encryption does, however, have its limitations. In particular, it is sensitive to Man-In-The-Middle attacks, an interception of the flow that can lead to espionage or even modification of a communication. It is during the first, unencrypted contact between the two servers that this flaw can be exploited. Once the flow has been intercepted, the attacker can compromise the integrity of the transfer. Here are two possible attacks:

Retreat attack

The principle of this attack is that, when the initial communication, the attacker will modify the server’s response recipient indicating its encryption capacity (step [4] of the above). It will instead inform the sender that the destination server does not allows only unsecured communication (no TLS). He can then, by continue to intercept the flow, read the unencrypted content of the traffic between machines.

Certificate modification attack

By default, mail servers do not check the validity of a certificate received. Historically, many had self-signed or invalid certificates. It is therefore to check the presence of a certificate, but not its status.

This allows the attacker to intercept traffic, modify the recipient server’s response (step [6] in the diagram above). It then indicates another certificate, corresponding to another server. The connection is therefore secure, but with the attacker relaying the server, reading and even modifying them as necessary. passage.

However, there are ways of closing these loopholes. Techniques that allow the sending server to verify information (encryption capacity, certificates, protocol version, etc.) transmitted during non-encrypted initialization of StartTLS communication.

How DANE works

DANE (DNS-based Authentification of Named Entities) is a standardized protocol (RFC 7672), which enables to indicate via a dedicated DNS record (TLSA) that a server uses TLS encryption. It also provides a fingerprint of the encryption key to make spoofing impossible. Installation of DANE implies two constraints:

– The fingerprint present in the TLSA record must be updated when the certificate is renewed.

– DNS communication must be secured by DNSSEC, to ensure that there is no tampering with the recovery of this print.

DANE operates at server level (not domain level). It must be configured on the mail server and in the DNS of the host name of this server. Technically, it is capable of securing any any TLS-enabled service, but it’s in messaging that it’s most current. This is currently the best solution for ensuring the safety of communications between servers.

Alternative to DANE: MTA-STS

MTA-STS (Mail Transfer Agent – Strict Transport Security) is a mechanism, initiated and promoted by Google, which enables policy, accessible via HTTPS, to inform sending servers if a destination server imposes TLS encryption. It uses a accessible via a Web server that indicates the servers of recipient’s mailbox. This document includes an identifier that must be updated in the event of policy changes. Unlike DANE, MTA-STS acts at the domain level rather than the server level, it is purely for messaging.

MTA-STS is considered less relevant than DANE, for two main reasons:

– The domain must integrate a Web server, which must be maintenance and safety.

– Certificate validation relies on known to the issuer, where DANE validates the certificate through its consistent with the footprint, taking into account, in particular, certificates self-signed or from certification authorities unknown to the issuer.

Fortunately, the two techniques do not interfere with each other. and are fully compatible. The ideal solution is to exploit both so that sending servers can choose which protocol to use. to use.

Altospam, the French email protection solution, uses DANE to protect its customers’ email systems. its customers, and can support them in setting up an effective MTA-STS to ensure optimum security.

To increase the security of your e-mail or understand the implementation of DANE and MTA-STS, you can follow the procedure described in the article: How to optimize e-mail security? Protecting is also a matter of securing your messaging flow and making sure authorized encryption protocols and algorithms.