What you need to know about using SSL/TLS to encrypt connections made by your email servers
When I was approached with the topic for this blog post, I happily agreed. Here’s some paraphrasing of how it went down:
“Would you be able to write a post about the importance of TLS in email servers?” asked Patrick.
“Sure,” I said.
Whew, that was a crazy conversation to relive! Like a whirlwind!
Then I started thinking about it for a bit. Are there really email servers out there that are not using encryption for transit? I’m not talking about end-to-end encryption like we have covered in the past (S/MIME, PGP, etc). I am referring to server to server or everything in between encryption to protect the data along the traversing route.
Surely, in this day and age, no one would leave their incoming/outgoing mail in plaintext traversing God knows which route to be intercepted and taken advantage of. Many people are using email services and there’s no way that they would be excluding transit encryption from their service. Data breaches cost them millions in lawsuits and loss of business and shame……Hmmmm…..
I went back to Patrick with a question.
“Do we have statistics or information about email servers not using encryption? My guess is it would be low. In other words, what prompted you to ask me about this article?”
Patrick replied, “I actually don’t. I thought it would be a good topic considering the importance of email and all of the aspects needed for security.”
[Editor’s Note: According to Google it’s about 93%, though its methodology was opaque so we’re not sure how accurate that is for the greater internet. Either way let’s say about 90-95% which is good, email encryption is a requirement for pretty much every compliance framework including HIPAA, HITECH, PCI DSS, Sarbanes-Oxley, GLBA, SB1386, SEC 17a-4, NASD3010, FRCP, FINRA, etc.]
OK. That makes sense. There probably are some email servers out there [about 7%, per Google] not using it at all, though undoubtedly a much larger percentage may be using out of date protocols or expired certs and may just need a refresh.
This article will go over where we are at with the email and transit encryption to make sure you are operating at an optimal safety level that is available.
Encryption in Email Servers
At this point, we probably have a general understanding of how TLS works but let’s summarize in case you are new to this.
Person A wants to send secure communication Human B. Person A and Human B have a pre-established certificate. Person A uses the certificate to encrypt the information and sends the encrypted information to Human B. The information is unreadable until Human B uses the certificate to decrypt the encrypted information.
If Human B wants to respond back to Person A with encrypted information, then Human B would use the certificate to encrypt the data and Person A would use the certificate to decrypt the message.
This is generally how encrypting/decrypting works. Now replace the people listed in this example with servers and other such connections. Same concept.
Now if Human B wants to respond back to Person A with encrypted information, then Human B uses the symmetric key that was just generated and they can now both encrypt and send, and receive and decrypt data to one another.
This is generally how encrypting/decrypting with SSL/TLS works. Now replace the people listed in this example with servers and other such connections. Same concept. This is how TLS works with email, which is a bit different than how it facilitates an HTTPS connection owing to the fact that email uses different protocols. But, there are still some distinct similarities:
- A handshake occurs
- Authentication occurs (though both parties authenticate in this context)
- Session keys are used to transmit the flow of emails.
Ebb and (Mail) Flow
The next step to this “understanding why to” article is the “understanding how” part.
In short, an email client sends an email to the outbound server. The outbound server will do a DNS look up, based off of the destination email domain, and that DNS’s MX record will determine which server to send the email to and, possibly, that server will determine if needs to be forwarded on until it hits the destination inbox’s Mail Delivery Agent (MDA).
It’s not enough to trust DNS MX records, which is a whole other trust issue altogether, but the SMTP (mail going out, MTA, etc) server and the mail coming in ( via POP3, IMAP, Exchange) need to be able to identify each other and have the correct keys to communicate with each other. And, depending on the route, there may be more than just one-ish hop email server communications. Mail Exchangers, proxy servers and else could be in place along the route. Each hop (should) call for an encrypted link. Often times, it does. Sometimes, it does not. Users would prefer sensitive information is encrypted along the way. End-to-End encryption helps assure that there is some sort of encryption the whole way through but layers of security are always, uh, better.
Respect Thy Securi-Tie
For the record, Securi-Tie is not a real word. I only made up that word because it rhymed. It’s a play off the word security.
To sort of springboard off the previous section, we should talk about security options that, while they would be set from the client side, would actually provide some instruction to the mail server side for security-related purposes.
When configuring an email client (Outlook, Thunderbird, etc), the default is for an unencrypted configuration. But, as is the point of this article, we typically want to go for the encrypted option. In a sense, it is not entirely up to the client: it depends on what the server side is able to support. Assuming that your inbound and outbound servers can support encryption, why wouldn’t you? If you order a steak at a restaurant and they offer you choice sirloin or Kobe(wagyu) ribeye at the same price, why wouldn’t you order the better-quality cut?
So, if you want to use TLS/SSL on your email (this is for the transit part and not the end-to-end, S/MIME part which is discussed in other blog posts), turn it on. Use ports 465 or 587 for SMTP (‘member, outbound mail) and 993 (IMAP) or 995 (POP3) for inbound traffic.
There is an interesting encryption protocol that is still used amongst email servers. It has its good with bad as is such with most things. Ultimately, I would say that its intentions are good but the real-world application is not quite ideal as it could. Ladies and gentlemen, that protocol is STARTTLS.
STARTTLS is a security protocol that basically is SSL/TLS. Quite simply, STARTTLS will take an existing plaintext and, therefore, unsecure connection, and attempt to convert it into a secure connection using TLS (or SSL). So, the security level of STARTTLS vs SSL/TLS is actually not different. If everything is set right, they will both encrypt information using TLS (or SSL).
The main difference is based on the state of a connection and/or the initiation of communication. STARTTLS does not guarantee encrypted communication. It basically means, ‘if the connection is unencrypted and you are able to, make this into a secure connection.’ If the connection node (likely a server) is unable to turn the connection into an encrypted connection, it may be up to the client end to decide how to handle it from there.
While I used the qualifying term of STARTTLS as “useful”, it could be considered less secure than selecting SSL/TLS. Standard SSL/TLS selection is basically, “Use encryption or bust.” STARTTLS is saying, “Um, if you could, please do so. If not, we may proceed based off other instructions.”
Here’s Some Conclusive Statements
Often times, the obvious needs to be stated and maybe overstated. So here it is, ahem: Use encryption. Especially for something that is so important, so crucial and integrated into seemingly the vast majority of any organizational structure that can carry make or break information. There is not much effort that needs to be put into it. Use both end-to-end and in-transit encryption. Two is better than one.
If someone feels that the extra effort to setup an email server to be encrypted versus unencrypted is not worth it, then that someone is not worth it. This is simply overstating the obvious. End-to-end encryption, such as S/MIME, takes a more involved approach but it also is worth it when adding layers and layers of security. But, there is no excuse to not take the time to setup and maintain secure links.
When visibility permits, any email path that might not seem secure or compromised should be held under scrutiny. And with that, be happy in your scrutinizing for a safer internet. Cheers!