Lead Image © nerhuz, 123RF.com

Lead Image © nerhuz, 123RF.com

Transport Encryption with DANE and DNSSEC

Safe Transport

Article from ADMIN 25/2015
By
Those who think that enabling STARTTLS in the mail client will make their mail traffic more secure are wrong. Only those who bank on DANE can be sure that a mail server or a firewall will not switch off encryption in transit.

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.

Figure 1: It is not enough to enable SSL/TLS in the mail client, because by default all participants use encryption-free communication as a fallback – and this can be provoked.

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).

Listing 1

Unfiltered SMTP Connection

$ 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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Posteo, Mailbox.org, Tutanota, and ProtonMail compared
    Encryption and server locations in Germany and Switzerland are sought-after attributes in the search for a more secure and reliable email service. We compare four providers who promise to protect your privacy.
  • Changes in Exchange Server 2013
    Exchange Server 2013 sees Microsoft complete the latest version of its groupware solution. In this article, we introduce new features in the server and reveal which features have been eliminated.
  • SSL/TLS best practices for websites
    SSL and TLS are very complex technologies. If you want to avoid wading through cryptography manuals to harden your HTTPS web server, read on for practical recommendations on establishing, securing, and optimizing your SSL/TLS configuration.
  • Attacks on HTTPS Connections
    HTTPS protects a connection from both tapping and manipulation, but only if a man in the middle hasn't already infiltrated the Internet connection. We highlight the weaknesses in HTTPS and demonstrate how to protect your client and server.
  • History and use of the mail utility
    The mail utility has evolved dramatically over the years, but it's still invaluable. We explore some ways to integrate it into daily admin tasks and add it to scripts.
comments powered by Disqus