November 3rd, 2015

Does TLS Corruption Spell the end of SMTP TLS?

We have seen discussions recently about how attackers can interfere with SMTP TLS, influencing connections, and causing them to be downgraded to insecure — SMTP without TLS.  E.g. Ars Technica’s – “Don’t Count on STARTTLS to Automatically Encrypt your Sensitive Emails“.

What is being discussed here is a very real attack on Opportunistic TLS. I.e. the kind of automated establishment of encryption that can happen when two email servers being their dialog and discover that “hey, great, we both support TLS so lets use it!”  In such cases, servers take the “opportunity” to use TLS to encrypt the delivery of an email message from one server to another.  Opportunistic TLS is great as it is enabling automatic encryption of more and more email over time (see: Who supports TLS?).

The problem is that the initial negotiation of the SMTP email connection, before TLS is established, occurs over an insecure channel.  A man-in-the-middle attacker can interfere with this connection so that it appears that TLS (i.e. the STARTTLS command) is not supported by the server (when it really is).  As a result, the sending server will never try to use TLS and the connection will remain insecure — transmitting the email message “in the clear” and ripe for eavesdropping.

So, Can you Trust Opportunistic TLS for Sensitive Emails?

No. This article and the surrounding discussion is completely correct in that you cannot trust opportunistic TLS to secure sensitive email messages!  This is because:

  1. The server’s configurations can change without notice (on purpose, by accident, or via malicious design) to stop it from supporting TLS and thus stop messages from being encrypted.
  2. A man-in-the-middle can modify the connections to prevent TLS from being negotiated.

So, is TLS Useless?

No. TLS is still very useful for sending sensitive email messages.  The problem with this discussion is that use of TLS is being posed as an option where on the one hand you have encryption and on the other hand you don’t.  This is true of Opportunistic TLS.  However, this is not true of Forced TLS.

With Forced TLS, the sending server:

  1. Knows that the recipient server should support TLS ahead of time.
  2. Tries to negotiate TLS with the recipient server when messages are to be delivered there.
  3. If use of TLS fails (e.g. for any of the reasons given above), then the message is simply NOT SENT — it is queued and re-tried until a TLS connection is established and the message can be sent, or the sending server gives up.

With Forced TLS, messages are never delivered insecurely.

If you couple Forced TLS with other email encryption technologies, e.g. SecureLine Escrow (which encrypts the message and stores it in a databases for the recipient to come and pick up via a secure portal), you have a system where you can deliver messages securely to any recipient, even ones that do not have a TLS-enabled email system.  Of course, there is also the question of if TLS by itself is “good enough” for your email encryption needs.  If it is not, then this issue is moot and you should stick with more secure technologies like Escrow, PGP, or S/MIME.

TLS is very useful and Forced TLS can be an important part of your email encryption strategy.

Users of LuxSci SecureLine who choose to use just TLS for secure email delivery are in fact using Forced TLS.  LuxSci automatically checks and confirms which domains support strong TLS on all of their email servers and force its use if they do, falling back to other technologies (such as Escrow) if they do not.  In fact, once LuxSci knows that a recipient domain supports TLS (because SecureLine users have sent to it and LuxSci has thus checked and confirmed), LuxSci Forces TLS to all recipients of that domain from all LuxSci users for added overall email security.

Leave a Comment

You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.