Email security is a common discussion I have with customers. This is typically due to discussions around why using Office 365 Message Encryption should be a standard practice for all businesses, but I often find myself needing to explain the difference between transport encryption and payload encryption.
Therefore, this post is not intended for my fellow IT professionals dealing with day-to-day messaging operations and systems, but for our typical employees and non-technical business leaders.
This post is not going to dive into why email security is necessary and when to use it, but simply highlight the difference between transport and payload security to understand why Office 365 Message Encryption is necessary.
What is Transport Encryption
Transport encryption refers to the encryption of the communication channel established between two messaging systems in which an email message is transported. Each email system has a Transport Layer Security (TLS) certificate that validates its identity and allows a secure and encrypted channel to be established.
So that definition probably doesn't help too much. Instead, think of transport encryption as cars traveling through a tunnel between two cities. Each city is represents an email system and the tunnel represents the communication channel.
Without transport encryption, we can look directly into this tunnel and see all the cars driving through it. But let's assume now that each city puts up a security gate at their end of the tunnel. This security gate symbolizes TLS certificates at each city. With these security gates, we no longer can gain access to the tunnel to see cars as they pass through it. This is how transport encryption works by preventing anyone from being able to see what is passing through the tunnel.
Limitations of Transport Encryption
The problem with transport encryption is that it is often "opportunistic", meaning that your email server will try to establish a TLS encrypted connection with the recipient's email server, but if the recipient doesn't support or is not configured properly to enable TLS, then no encryption is used. Sure, we can tell our email system to require TLS so that nothing is ever sent out not using an encrypted connection, but this could result in failures to send email to some recipients. It becomes very time consuming for messaging administrators to ensure all outbound email recipient systems support TLS and to assist end-users when one doesn't.
Requiring TLS is typically something done on a per-recipient domain basis, meaning that if you have a specific partner or vendor that you want to always require TLS because you know they support it, you can ensure all email going to that partner or vendor goes over an encrypted connection. Again, this is typically done for a select number of recipient domains as it would be very complex and time consuming to manage a large set of these.
Not only is transport encryption typically done as "best effort", we can also only try to manage an encrypted connection from our email server to the next "hop" in the message route to the recipient. An email message may bounce around through several messaging systems until it reaches its final destination. Transport encryption can only be managed or ensured from our email server to the next system. If the email goes on past that next system to any others, we cannot control or require TLS between future routing.
For example, let's assume we are sending confidential document to a supplier at ABC Inc. So we send the document as an attachment to bob@abc.com. We have our email system set to require TLS to abc.com, but what we don't know is that ABC Inc. has a spam filter sitting in their DMZ which receives all their inbound email. Our email system can establish a TLS connection to ABC's spam filter, but the spam filter does not establish a TLS connection to the internal ABC server.
In this scenario, someone could maliciously intercept the message between the spam filter and the back-end server even though we required TLS to the abc.com domain.
Payload Encryption
The solution to this is to not depend on the transport security. This doesn't mean that you do not want to use transport encryption if possible, but for instances where highly sensitive information is being sent, you want to encrypt the message itself so that it doesn't matter whether transport encryption is used or not.
Going back to our tunnel example, let's assume now that instead of cars going through the tunnel, we are now loading each car into a container of a semi-trailer truck. Now we can no longer see the cars themselves, so whether our tunnel has gates on both ends or not doesn't matter. Even if the truck carrying a car goes on past the next city and travels through four more cities, it doesn't matter if those other cities are tunnels or open roads.
The benefit of payload encryption is that we no longer rely on the transport connections, but our message is now protected from our email server all the way through to its final destination.