Part 3 of 5: TLS Encryption Between Email Servers
What Is It?
Encrypting emails between the sending and receiving servers sounds like a really good idea and when you think about it, it is. We often think of encrypting the communication between our endpoints and servers and between servers themselves to ensure our data is secure. Many internet sites require secure (HTTPS) connections and we’re heading towards this becoming the norm rather than the exception. The next time you are browsing the web for anything and moving site to site, look at the browser bar and watch how many sites are secured with certificates.
When you access a web-based email service such as Outlook or Gmail, it is secured, and the certificates used are issued by trusted Certificate Authorities such as GoDaddy and Digicert. The certificates built into your computer (or installed by policy, depending on your situation) simply acknowledge these as trusted certificates and trust communication from servers that have one of these certificates provided it is valid and used modern cryptographic elements.
When it comes to communication between email servers, such as between a server located at company A and a server located at company B, it becomes a little different. As a user at company A, odds are your connection to your email server is secure – or it should be. The same would go for a user at company B. So therefor when you, at company A, send a message to the user at company B, it should be secure end to end, right? Not exactly. The connection between the email servers is where things can come unstuck.
Where Do I Start?
SMTP, like HTTP, is natively unsecured. Like web traffic that used good old port 80, mail traffic can be likewise intercepted unless a secure connection between mail servers is configured. SMTPS made an appearance for a while but is now considered deprecated although some organisations continue to use it. Through Opportunistic TLS, STARTTLS has gained considerable traction in recent years (thanks, Mr. Snowden!) Many popular providers have begun to use it so if you rely more on cloud-based services for your email exclusively, you’ve probably already done all you can.
That said, on premise email solutions are still popular and many organisations I deal with have on-site Microsoft Exchange servers or in hosted data centres. I think by having your own mail server lulls some of us into a false sense of security; we must remember that as soon at that data leaves our site, it’s at the mercy of the big, bad internet. Hence, the emphasis on encryption. Signing your outbound email has become a more popular option over the past several years.
The problem seems to arise when It’s sent to an organisation that can’t treat the encrypted message with the same level of respect. It’s like locking a parcel in a box but the person for whom it is intended doesn’t have the key to open it. This can result in a variety of issues but the long and the short is that both sides need to agree on secure email communications. Within your own organisations, it’s straightforward but between separate organisations, the waters become muddied.
I would start by asking a few questions. Do we currently encrypt our email? If yes, how do we encrypt it? If no, do we need to and how do we go about setting it up? What are the risks and rewards of encrypting our emails between outside organisations and internally amongst ourselves? It can get tricky quick, so don’t hesitate to call in the experts for guidance.
How do I make It Work?
Configuring email encryption can be a bit of a process, especially when you’re dealing with server to server, which is what this article is about. Let’s assume you have the client and policy side of things sorted out. You need to acquire a certificate for the purposes of securing your email from a trusted CA. Using your own, internal CA may seem attractive due to cost, but the recipient would need to have certificates to send and receive secured messages from you and you would likewise need theirs. If they choose to only trust the commercial CAs, then you have no choice anyway. That, and many implementations would never accept self-signed certificates.
With certificates sorted, configured your email server and depending on what you use, this can be several products with their own requirements. Consult the vendor for guidance or bring in the experts to help. Bear in mind that you may need to configure the server to both offer and accept, but not require, TLS for SMTP.
This way, messages that arrive unencrypted can still be accepted. With it configured on your side, you’ll be sending them encrypted… there is no guarantee the recipient will be able to accept it, though, so if you’re going to this extent, you should find out. Fortunately, many service providers won’t present a problem – it will be the organisationally owned and managed systems that you might stumble over.
I often suspect that the resistance to setting up secure mail is due to the additional cost and overhead., but if you’re really after secure email, it’s worth it. Otherwise, you may wish to consider other means. It’s still good practice, after all, to not send anything confidential by email in such a way that it can be intercepted.
Pitfalls?
Encryption, by its very nature, has its own pitfalls but when correctly configured and used, has a lot fewer. Email inspection, which I covered much earlier, would must be done on an unencrypted message, so if it is done anywhere in the middle, it likely won’t work as it should. In this case, you need to have that layer after the message arrives and is decrypted and should have this consideration on the client if the message is encrypted all the way from the sender to the recipient. Inspecting encrypted traffic is becoming more popular with more traffic in general now encrypted for everything.
You would like to think that the sender, by using all the client to server and server to server encryption, is supplying valid information but that is a dangerous assumption. Bad things can just as easily be encrypted as good things. Think defence in depth and think of all those layers. If a malicious message arrives in a user’s inbox, we need to be sure that their system, their endpoint, and their mindset can deal with it correctly.
Ghosts in The Machine?
The idea that all email needs to be encrypted may be overkill and can introduce a lot of unnecessary complexity. Be sure that if you’re going to go down this road that you are doing it for the right reasons and not “just because”. There are other means of securely communicating apart from email and you’ve no doubt already invested in them and secured them. So why expend more time and money and risk more complexity if you don’t must?
Spend the time to understand why. Why do you need this? Also understand why you don’t. Evaluate the risks and benefits before blindly forging ahead with either choice and consider what your other options are. If all that you risk losing is your weekly footy tips, then look elsewhere. If you regularly share more sensitive information, then this might be worth thinking about.
Anything Missing?
Review your client to server configuration and be sure you are secure in that way if you choose to go ahead but remember that on the other end, their client to server connection might not be as controlled. There are a lot of unknowns and potential weak links. Personally, I will always recommend against sending anything sensitive by email but securing your email, or as much of the chain as you can, is probably a good thing.
Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party. The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such. Appropriate legal advice should be obtained in actual situations. All images, unless otherwise credited, are licensed through ShutterStock