Opportunistic TLS vs Forced TLS for SMTP

Email sometimes seems like magic because of how quickly messages are transmitted across the internet. While the rapid delivery speeds justify this presumption, a lot must happen for an email to reach you. Email sending relies on a protocol called the Simple Mail Transfer Protocol (SMTP) to make its way across the internet to your recipient’s server. From there, the recipient uses another protocol, such as ActiveSync, POP3, MAPI, IMAP, or a Web-based interface, to pick it up and read it.

 

Unfortunately, these protocols aren’t always secure by default. Under its original design, emails are sent as plain text. 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 are aware of this glaring security hole, and they have introduced several mechanisms that can be leveraged to protect email. This article reviews how SMTP TLS works and the differences between opportunistic TLS and forced TLS.

 

What is SMTP TLS?

First, let’s discuss TLS in general. Transport Layer Security (TLS) is a cryptographic protocol that can authenticate both parties in the email-sending connection to provide 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 protects your traffic when you connect to a website.

 

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

 

A weakness of TLS is that not all SMTP servers support it, although the situation has improved significantly in recent years. At the end of 2013, Google reported that just 27 percent of its inbound 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 TLS protocols have evolved to address modern security concerns. The TLS of five years ago is no longer considered “good enough” for use in situations where regulatory compliance and high security are needed. When considering only those messages that can be sent using a modern, secure version of TLS, LuxSci sees that, on average, only 85-90% of domains support it.

 

While the overall improvement in TLS support is significant, the lack of universal TLS support is a big issue for organizations bound by HIPAA regulations and compliance concerns.

 

Opportunistic TLS vs Forced TLS 

Let’s assume your organization is diligent and understands the importance of protecting health information contained in emails. At a minimum, it would want its servers 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?

The servers can be configured in two ways:

• To use TLS whenever it is available, but to send messages without TLS whenever it is not supported. This is known as opportunistic TLS. Messages are delivered insecurely if TLS support is unavailable.
• To use TLS at all times. When TLS is not supported, the message is either not sent or is sent using another encryption mechanism. This is known as forced TLS. With this method, messages are always sent securely or are not sent at all.

Let’s compare the two methods and the pros and cons of each.

Opportunistic TLS

Opportunistic TLS for SMTP can be helpful in many situations because it will protect most emails in transit. However, securing “most” emails is not sufficient to meet HIPAA compliance requirements. Healthcare organizations that want to transmit protected health information using email must protect patient privacy and secure the data- no exceptions. Even a single instance of unprotected ePHI in an email message could be considered a HIPAA violation.

 

If a healthcare organization uses opportunistic TLS to protect ePHI in emails, it cannot guarantee that all data is protected and secured. It would result in privacy breaches for many patients, quickly inundating the organization with HIPAA penalties.

 

While it’s clear that opportunistic TLS isn’t suitable to meet the HIPAA compliance requirements for sending ePHI, there are other security issues. The handshake occurs in plaintext, which leaves it vulnerable to man-in-the-middle attacks. Attackers can insert themselves into the authentication process and alter messages to divert them to insecure channels.

 

This means that opportunistic TLS allows threat actors to prevent data encryption, ultimately allowing them to access the email. Poorly configured servers can also lead to similar downgrade attacks. While opportunistic TLS is sufficient in many cases, it leaves a not insignificant number of individuals susceptible to an attack or breach of personal information. 

 

Forced TLS

Compared to opportunistic TLS, forced TLS is a more secure option, particularly when you need to meet HIPAA compliance requirements. Forced TLS prevents threat actors from downgrading a TLS connection and emails from being sent insecurely. 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?

 

When using forced TLS, there are three possibilities for what happens to the message:

1. The recipient’s server supports TLS; the message is sent using TLS.

2. The recipient’s server does not support TLS, and the message is not sent at all. (TLS Exclusive)

3. The recipient’s server does not support TLS, so the message is sent using another encryption mechanism. 

 

If the messages aren’t business or mission-critical, using something like LuxSci’s TLS Exclusive feature allows you to drop messages that can’t be sent using TLS while delivering those that do support TLS. This can be useful for marketing messages, especially when secure workarounds are too much effort for the recipient to justify their use.

 

If the messages are critical, using another encryption method like LuxSci’s secure web portal pickup acts as an automatic fallback option, allowing you to send secure messages to anyone with an email address. If the server identifies the recipient as unable to support TLS, the message is sent using an alternate encryption method to ensure secure email delivery. 

 

While these solutions will help limit your organization’s risks, you must 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

While opportunistic TLS can be an excellent way for organizations to secure the bulk of their messages, it is too complicated and unreliable for sensitive situations. Using semi-secure mechanisms like opportunistic TLS can make companies sending ePHI vulnerable to attackers and breaches.

 

Instead of relying on opportunistic TLS, your organization should use forced TLS with a fallback to secure web portal pickup to ensure all messages are securely transmitted. You can contact our team to find the best solutions for your company’s unique situation.