Safe Transport

Manual and Automatic

A TLS policy defines requirements for an SMTP session with an SMTP server. The basic requirement that TLS is encrypted during transport, or is omitted, effectively prevents a session downgrade. If the transport conditions are not fulfilled, the email stays in the queue of the server, which is ready to transmit, until it bounces once the wait time runs out.

Transmitter-side TLS policies are rarely used. Completely secure encryptions are too complex because of the large number of communication partners involved. A local policy that, in addition to the "Must offer TLS" requirement, also defines conditions such as "Must be distinguishable through a specific fingerprint in the certificate" is fragile. Once the remote site changes a condition, local requirements are grasping at nothing, and transport comes to a standstill.

The protocol extension DANE SMTP frees the admin from this predicament. If you enable DANE SMTP, then the SMTP client will from then on check whether the target is in a DNSSEC-signed domain and whether a Transport Layer Security Association (TLSA) Resource Record (RR) exists for the MX to be controlled. The client is supposed to judge the existence of a TLSA RR like a policy. It is a policy violation if the server referenced in the TLSA RR does not provide an STARTTLS, and transportation must then stop.

Protection Against MITM

DANE SMTP also protects against man-in-the-middle (MITM) attacks. A successful MITM attack poisons, for example, the DNS of the victim with fake resource records (DNS poisoning). Fake MX records then point to the attacker's SMTP server. The attacker's server pretends to accept messages for the allegedly correct target domain. The attacker can even provide STARTTLS with a valid certificate.

An uncontrolled SMTP client will accept the certificate and innocently handle the attacker-sensitive messages via an encrypted connection. This is possible because most message transfer agents (MTAs) only check the certificate's common name (CN) for identity verification.

Certified Deception

An attacker in possession of a certificate with a matching CN can easily fool the client. The attacker does not even have to work hard: A self-signed certificate will suffice. Most clients accept self-signed certificates without batting an eyelid. As long as the CN is correct, encryption takes place no matter who is behind the certificate. Signed certificates from public certification authorities (CA) do not protect against this either, because the clients by default only check the CN, not who issued the certificate.

A design error exacerbates the whole situation: CAs can create valid certificates for the same domain independently from one another. Attackers took advantage of this particular vulnerability when they broke into the DigiNotar [3] and TurkTrust [4] certification authorities and there exhibited certificates for the domains of well-known companies.

After these incidents came to light, the compromised CAs' root certificates were disabled in haste. Until discovery, however, the attackers had access to "official" certificates. They could even fool SMTP clients that only accept certificates from well-known CAs.