Opportunistic TLS for SMTP

If you want to make sure your emails are secure and private, opportunistic TLS for SMTP won’t quite cut it. To explain why, first we have to step back a bit.

Most people don’t put a lot of thought into how their emails are sent and received, so it’s not unusual for them to think it works akin to teleportation or magic–that messages somehow just appear right in their inboxes.

While the rapid delivery speeds may seem to justify such presumptions, there are actually a bunch of steps under the hood. When you send an email, it uses a protocol called the Simple Mail Transfer Protocol (SMTP) to make its way through to your recipient’s server. From there, your recipient uses another protocol such as ActiveSync, POP3, MAPI, or IMAP, or a Web-based interface, to pick it up and read it.

Unfortunately, these aren’t always secure by default. Under its original design, emails are sent as plaintext. This means that anyone along the email’s journey can see (and even change) their contents. This can include those in charge of the servers, the government, and even hackers that intercept the data.

Thankfully, engineers weren’t completely oblivious to this glaring security hole, and they have introduced a number of mechanisms that can be leveraged to protect email.

TLS & SMTP

To the rescue came Transport Layer Security (TLS), a cryptographic protocol that can authenticate both parties in the connection, as well as providing confidentiality and data integrity. TLS is widely used, and you are probably most familiar with it as the “S” in HTTPS. It stands for secure, and it’s the part that protects your traffic when you connect to a website.

Just like in HTTPS, SMTPS is the secure form of SMTP, and again it uses TLS to protect the SMTP data. While this extension to the original SMTP protocol is a great security addition, it isn’t always used by default.

Not all SMTP servers support TLS, although the situation has gotten significantly better in recent years. At the end of 2013, Google reported that just 27 percent of its inbound emails and 39 percent of its outbound emails were protected by TLS during transit. The figures have since jumped to 94 and 91 percent, respectively.  Additionally, not all TLS support is equal, as the security landscape and the TLS protocol has been evolving:  The TLS of 5-10 years ago is no longer considered “good enough” for use in situations where regulatory compliance and high security are needed.  In these cases, everyone needs modern systems.   When you take into consideration only those messages that can be sent using a modern, secure version of TLS, LuxSci sees that only 85-90% of domains support it.

While the overall improvement in TLS support is significant, the portion that doesn’t support TLS is a big issue for organizations that are bound by HIPAA regulations.

Opportunistic TLS for SMTP

Let’s assume that your organization is diligent and that it understands the importance of protecting its emails. It would therefore want its server configured to use TLS whenever possible. But what happens if an email is supposed to be delivered to a server that doesn’t support TLS (or doesn’t support “good enough TLS”)?

It has two choices:

• To use TLS whenever it is available, but to send messages without TLS whenever it is not supported. This is known as opportunistic TLS.
• To use TLS at all times. When TLS is not supported, the message is not be sent or is sent via some other encryption mechanism. This is known as forced TLS.

Opportunistic TLS for SMTP can be helpful in many situations, because it will protect the vast majority of emails in transit. But 85-90% isn’t good enough for organizations regulated by HIPAA that need to include ePHI in their emails. Even a single instance of unprotected ePHI in an email could be considered a HIPAA violation.

If a healthcare company uses opportunistic TLS to protect ePHI in emails, the small percentage of servers that don’t support TLS would lead to catastrophe. It would result in privacy breaches for a significant number of patients, quickly inundating the organization with HIPAA penalties.

While it’s clear that opportunistic TLS isn’t suitable for sending ePHI, there are also less obvious  weaknesses. The handshake occurs in plaintext, which leaves it vulnerable to man-in-the-middle attacks. Attackers can insert themselves into the authentication process, and then alter messages to make it appear that TLS isn’t available, even when it actually is.

This means that opportunistic TLS makes it possible for threat actors to prevent the data from being encrypted, ultimately allowing them to access the email. Poorly configured servers can also lead to similar downgrade attacks.

Forced TLS

Compared to opportunistic TLS, forced TLS is a much better option for security, particularly when it comes to protecting ePHI. Forced TLS prevents threat actors from downgrading a TLS connection to one without, because emails will not be sent insecurely.  They either go via TLS, or they fall back to another encryption mechanism (if supported by the sending system), or they are not sent at all.

While this is great for protecting ePHI from attacks, it does present a problem—how can you safely send emails to servers that don’t support TLS?

If the messages aren’t particularly important, something like LuxSci’s TLS Exclusive feature allows you to simply drop them, while still delivering other messages to the servers that support TLS. This can be useful for certain marketing messages, especially when secure workarounds are too much effort for the recipient to justify their use.

If the messages are critical, options like LuxSci’s portal pickup provides an automatic fall-back option which allows you to securely send messages to anyone with an email address.

While these solutions will help to limit your organization’s risks, you need to be careful with the TLS configuration details. TLS can be complex, and some older implementations aren’t secure enough for the current threat landscape. In these situations, it’s best to act cautiously and force a high level of security or rely on an email provider that can be trusted to take on that responsibility for you.

Why You Should Avoid Opportunistic TLS for SMTP

Opportunistic TLS is much like quasi-HIPAA compliance. While it’s a great way for organizations to secure the bulk of their messages, it ends up being complicated and not reliable enough for sensitive situations. These types of semi-secure mechanisms can make companies that deal with ePHI incredibly vulnerable.

Instead of relying on opportunistic TLS, your organization should use forced or exclusive TLS, with a fallback to something like portal pickup. You can contact our team to find out the best solutions for your company’s unique situation.