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
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
The diagram below explains how it works and the steps involved.
secure SMTP communication under StartTLS when sending an email from
user “email@example.com” to “firstname.lastname@example.org”.
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:
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  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
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  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.
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
(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
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 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.
Test Altospam’s solutions!
Thousands of companies, CTOs, CIOs, CISOs and IT managers already trust us to protect their e-mail against phishing, spear phishing, ransomware, …