Safe Transport

Communication needs privacy. It forms the basis for confidential and binding exchange. A typical email does not offer any privacy as it passes through the network in cleartext. Anyone who reads the network traffic has full access to the content of the message, so anyone who wants privacy needs encryption. PGP and S/MIME or SSL and STARTTLS are suitable methods for encrypting email. The first two methods encrypt the message; the others encrypt the transport.

Not Always Safe Transport

Transport encryption (Transport Layer Security, TLS) is attractive. It provides a useful level of protection and is transparent to the user. That is good because it saves support costs and allows users to concentrate on the contents of the communication rather than the encryption.

Many admins believe it is sufficient to generate the required certificates for encryption and enable STARTTLS in the SMTP Server and Client (Figure 1). They think that the transport is safe from then on. They are wrong. Transport encryption has some principle-related vulnerabilities, which this article discusses and justifies.

Session Downgrade

STARTTLS is a protocol extension of the original SMTP. Two conditions must be met to establish a TLS-protected connection. The server must both have control over and offer ESMTP (Extended SMTP), and the STARTTLS extension must be enabled in the server.

A client will only know whether these conditions are met if the server sends its "SMTP Banner" to greet the client. In the banner, the server establishes its current status through a status code, often followed by its name and – importantly – the string ESMTP (Listing 1).

$ telnet mail.sys4.de 25
220-mail.sys4.de ESMTP Postfix
EHLO client.example.com
250-mail.sys4.de
250-PIPELINING
250-SIZE 40960000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

If the server does not send an ESMTP in the banner, then it does not (or at least appears not to) support ESMTP, and communication can only take place without transport encryption. If the string is missing or the server sends SMTP, then the client must assume that the server does not have control over any SMTP extensions.

The SMTP clients in popular mail servers are generally set unconditionally to transport. They perform "opportunistic TLS." In other words, they try to bring about encrypted transport if the server provides STARTTLS. They switch back to the original SMTP if ESMTP is missing in the server's banner. You do without transport encryption because there is no "opportunity" to use it.

Security solution providers benefit from this behavior just as some access providers do. They filter SMTP connections in the firewall (called SMTP fixup by Cisco), in the desktop SMTP proxy (McAfee), or on WAN connections [1] and remove the ESMTP in the banner.

Specifically Insecure

The providers receive access to the session data and the contents of the message using this deliberately administered session downgrade. According to them, a message can only be checked for malicious content (malware, spam) if unencrypted. In this case, this argument is not tenable: Messages can also be transported unencrypted to the server and then checked for undesired contents unencrypted in the server. This is exactly what happens a million times a day.

Conspiracy theorists may speculate about possible reasons against the backdrop of the NSA affair, but the fact remains: Transport encryption provides an attack vector that is applicable, for example, with the STRIPTLS attack [2]. Such attacks are possible because conventional TLS does not provide policy components. The server does not have a tamper-proof channel through which it can indicate to the client that it has control over STARTTLS. Only your own TLS policy and enabling another SMTP extension can provide help here.

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.

Identification Criteria

The problem here is with the criteria used to identify the counterpart. Anyone who pays attention only to the hostname mapped in the certificate's CN can easily become a victim of deception. Names are just hollow words. A certificate's fingerprint, on the other hand, is unique. It cannot be faked – as of the end of 2014. An SMTP client that pays attention to the fingerprint cannot be taken in by an MITM attack.

An SMTP client that performs opportunistic TLS does not combine a certificate's fingerprint with a specific identity. This only happens if the administrator assigns one or more (SMTP cluster) fingerprints in a target domain TLS policy (certificate pinning).

Certificate Pinning

Those who take certificate pinning seriously do not simply fix the fingerprint. They ascertain the identity beforehand and worry about the remote station's fingerprint. They would then look for a suitable partner in the target domain who could read out the used certificate's fingerprint. They can then compare the two fingerprints. The fingerprint can then be fixed if the two match – a rather complicated and labor-intensive process.

DANE SMTP also tackles this issue: It automates the identification. The TLSA RR publishes the fingerprint of the certificate used along with some descriptive statements about the certificate. A DANE-enabled SMTP client can retrieve this information in a trustworthy fashion via a DNSSEC-signed domain and compare it automatically with the fingerprint of the counterpart.

The Request for Comment (RFC) authors have even thought about a certificate's rollover. Anyone who wants to use a new certificate with a new fingerprint has to temporarily publish two TLSA RRs for the same resource (Listing 2 shows an RR example). For the SMTP client, it only matters that one of the published TLSA RRs fits. The old TLSA RR can be removed as soon as its DNS time to live (TTL) has expired.

$ dig TLSA _25._tcp.mail.sys4.de +short
3 0 1 9273B4E9040C1B9EE7C946EFC0BA8AAF2C6E5F05A1B2C960C41655E3 2B15CBE

Considering the aforementioned CA vulnerabilities, anyone who would like to switch to self-signed certificates will receive support from DANE SMTP once again. A TLSA RR allows publishing the fingerprint for a self-signed certificate or even just the reference to the root certificate from a proprietary CA. The signed DNSSEC domain co-signs in both cases.

Using DANE SMTP

A DNSSEC-verified DNS resolver is a prerequisite for DANE SMTP. It should work on the same host on which the DANE-enabled MTA is also operating. If a DNSSEC-enabled domain is having problems (e.g., with its signature), this is an indication of a security problem. Clients therefore are not allowed to use information about such domains because the reliability of the whole domain is called into question.

Conventional resolvers do not detect such problems. Only DNSSEC-enabled ones notice DNSSEC errors and suppress the response. If /etc/resolv.conf lists multiple resolvers, then they all need to be DNSSEC-enabled to ensure a seamless trust.

A final test makes sure that everything worked. Postfix should log Verified TLS … when transporting email to sink@dane.sys4.de:

Dec  9 13:44:23 mail postfix/smtp[14944]: \
  Verified TLS connection established to dane.sys4.de[194.126.158.134]:25: \
  TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

The admin should set the smtp_tls_loglevel parameter to 1 to obtain this protocol.

The DNS Resolver Unbound

Unbound [5] is a good DNSSEC-enabled resolver. It is easy to set up, it's quick, and it caches DNS queries. After installation, running unbound-anchor is usually sufficient to load the root certificates for the DNSSEC trust chain. The additional call unbound-control-setup generates local certificates for secure communication of the command-line control program unbound-control, which Unbound manages easily.

After the start, Unbound binds itself to the address of the local host by default. The dig query of a DNSSEC-enabled domain (Listing 3) ensures that Unbound can recognize and verify DNSSEC. The additional ad (authenticated domain) flag in the answer's header area indicates a successful query.

$ dig @localhost +dnssec sys4.de
; <<>> DiG 9.9.5-3-Ubuntu <<>> @localhost +dnssec sys4.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15587
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3
[...]

Up to the release of this article, Postfix only provided full DANE-SMTP support. The main reason for this is that Viktor Dukhovni, one of the DANE SMTP RFC authors, is also a leading author of Postfix. His reflections on DANE SMTP flowed into Postfix, and he traced his experiences back into the RFC.

Only Postfix from Version 2.11.1

DANE SMTP requires at least Postfix 2.11.1. Once the SMTP client is fundamentally configured for TLS, only a few simple steps are required, and Postfix can handle DANE-SMTP servers. The parameter smtp_dns_support_level instructs Postfix to make DNSSEC-validating queries to the resolver. The new TLS policy sets the dane option for smtp_tls_security_level (Listing 4). With immediate effect, Postfix queries via DNSSEC as to whether the target domain MX(e) records have TLSA RRs and checks to see whether their fingerprints match those of the server.

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

Enabling TLS Policies

Those who want to publish a TLS policy must enable their domain for DNSSEC. Just over a third of German registrars currently provide the infrastructure to host a DNSSEC-enabled domain. If you're running your own DNS server, you can, of course, also operate DNSSEC-enabled.

The steps required for this also vary depending on the product used: DNSSEC works with the current BIND without any problems. Older name servers (e.g., djbdns) still have problems. In any case, it is important to renew the signatures of a DNSSEC-enabled domain meticulously within your TTL. If the signatures run out without being renewed, the domain will no longer be considered trustworthy, and DNSSEC-enabled resolvers will then ignore all requests.

TLSA RR

The administrator still needs to enter a matching TLSA RR in the signed zone of the MX. A TLSA generator [6] helps create the resource record. Anyone who has a CA-signed certificate selects the 3, 1 radio buttons and then 1 again (Figure 2), copies the certificate into the designated input field, and then specifies how the related service is reached.

The generated output is then transferred into the zone file. The new entry for requests is available after updating the serial number and a reload. The policy is now armed. The Sys4 DANE validator [7] from email specialist Patrick Koetter helps by checking thoroughly whether the published TLS policy is without defects.