SSL/TLS Encryption and Email Servers
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!
Don’t Get Phished.
Email is the most commonly exploited attack vector, costing organizations millions annually. And for SMBs, the damage can prove fatal: 60% fold within 6 months of falling victim to a cyber attack. Don’t be one of them.
*** This is a Security Bloggers Network syndicated blog from Hashed Out by The SSL Store™ authored by Ross Thomas. Read the original post at: https://www.thesslstore.com/blog/encryption-and-email-servers/
