As most people are aware, the need for secure messaging, email encryption or email compliance is on the mind (or should be) of almost all managers inside every business. The need for TLS (Transport Layer Security) can vary from avoiding a data leak, ensuring there are no prying eyes on confidential information or even something as simple as validating that someone received your message.
Working for an email encryption and security company I constantly get questions and inquiries about TLS and why using TLS isn’t “good enough”. Most of the time these questions are immediately followed by statements like “It’s good enough, and it’s free!” Free? Sure, but remember there is no such thing as a free lunch!
Here are a few different points that should be considered before making a decision on whether TLS is “good enough” for you and your organization’s email needs.
What is TLS?
Before any comparisons or pro’s and con’s discussion, we need to establish what TLS actually is and where it is used. TLS stands for Transport Layer Security and is intended to secure the communications between two points. When we talk about TLS in relation to a web browser we have the little “lock” icon on our URL bar showing a secure connection from the web server to your browser. This means when you submit a form with your credit card information on it, no one can snatch that data if they intercepted your web session.
Same thing for email. When you have one email server send a message to another email server over TLS, the connection itself is encrypted so no one can intercept the payload information. But, the actual data itself is still unencrypted. It’s secure and compliant because it was sent over an encrypted channel.
When we talk about encryption in every day talk, we have openly accepted and use the “TLS” acronym to imply that it only applies to email and “SSL” as it applies to the web. In reality you can apply TLS encryption to a variety of protocols, including HTTP for the web and SMTP for email. For clarity, the predecessor of TLS is SSL or Secure Socket Layer, which was more commonly used on the web before email so hence the common associations of the acronyms. Now that we have a bit of a primer we can take a deeper dive and talk about workflows as they relate to email.
TLS and SPAM/Anti-Virus Workflows
When we talk about servers we know that if TLS is used between servers then that connection is secure. It’s assumed that if two servers have TLS then the message is secure and they don’t need to worry about anything. This is a VERY common misconception that while mostly accurate needs to have some additional questions asked of the recipient mail server.
Most companies have some kind of SPAM and Anti-Virus service implemented. We know that those services or appliances look at messages and if they are deemed “OK” they are then delivered to the receiving mail server. The question needs to be asked does SPAM or Anti-Virus service actually sends messages to the receiving server over TLS or not. Just because a sender sent the message and something received it via TLS does not mean that the whole connection to the receiving server is encrypted. This is a potential point for a breach. So it is important to ask recipients where auto TLS delivery or a forced TLS delivery is in place, to see if true end-to-end TLS is implemented, or if there is a gap.
TLS and Replies
As an email recipient sending a reply, we can have a scenario where the recipient needs to reply securely. Just because a message is received from someone over TLS there is no guarantee that the recipient’s sending email server will use TLS to send a reply. The question that needs to be asked of the recipient’s IT team is about priority of use. For example, will TLS always be used? Is there a fallback to an encryption or delivery provider in situations where TLS is not available or is there even support of TLS for sending messages?
The number of organizations that I see where they accept TLS due to having some kind of email SPAM or AV service but don’t have TLS in use for inbound or outbound email on their server is more than I would like to admit. So if you are adopting TLS as your primary method for security it’s important to establish trusted relationships with the people you send messages to and ensure that you (as the sender) have your email server forced to send messages only to those recipients via TLS.
Another point to be considered as a sender is to determine if you want your message to be available to the recipient in their own mailbox with no secondary level of protection. Traditionally the answer is yes, but what if you are sending a confidential document or sensitive information like a routing or account number and the someone you are sending to has a traditional email account from a provider like Gmail. We traditionally would feel OK since we know that Gmail does support TLS. However we often don’t consider the risk of have the account itself breached. Putting it simply, if someone has their public email account compromised then in all cases the confidential information you sent them is also compromised.
Yes, in the eyes of compliance you are covered but there are certain ethical and best practice issues that you should take into account. By forcing people to use two-factor authentication, or to log into a portal with a separate password, or even have a message exist for a finite amount of time, you can ensure security for confidential information regardless of whether the recipient’s primary account is compromised.
As a recipient there isn’t too much you can do. In situations where you are the one receiving content, you can insist that people send you confidential messages through their own secure portal system. In many cases you can leverage a custom portal or messaging center if made available by your vendor. A best practice should always be to not send sensitive information unless it is encrypted. Most secure email providers (DataMotion included) provide a means for you to reply to the sender securely. Alternatively you could initiate a new secure message so that your recipient can reply to you securely as well.
In closing, TLS is great for making sure that messages and data between servers and systems are encrypted from prying eyes. However, it is only part of a somewhat potentially complex equation and it is in your best interest as a sender or a recipient to ask some key questions around how your information is sent, stored and delivered to its final destination. In many cases just because there are open standards or something may be free, it is commonly not the full answer to your needs. TLS is the foundation for solutions but may not be a solution in itself.