Way back when, e-mail was from server-to-server, and really client-to-server as well, without much thought to security. Messages were transmitted in plain text (no encryption) and the only people reading your mail (literally) were the system administrators who ran the email server. Of course, those system administrators knew what was up and understood the later ramifications these open networks could have.
In 1991, Phil Zimmermann developed encryption software that would allow users to digitally sign and/or encrypt their e-mail in hopes of improving security on this open system. Pretty Good Privacy (PGP) (RFC4880) was the name of his creation and the end result was that users could protect their data in a somewhat standard way. Unfortunately, use was limited and it didn’t address the problem of a third-party gaining access to whom you were communicating with.
There had been rumors, and common sense should have told us as much, but it wasn’t until 2013 when Edward Snowden let the world know exactly how vulnerable our communications were did people start to pay attention. It was at that point that we realized just what the U.S. Government, specifically the National Security Agency (NSA), had been up to.
The NSA, it was revealed, had been "partnering" with many information technology companies to help obtain data created and stored by individuals within the United States and around the globe. To supplement this data, as sometimes they actually ran into businesses that wouldn’t quietly go along with their plans, they began to tap into portions of the Internet so they could capture the data as it was moving between the clients and servers and between servers as well. While it hasn’t been a large focus in the United States, it should be remembered that if the U.S. Government was doing this, it is almost certain that other countries are too and who knows what they are doing with your data.
It’s difficult to accurately count the number of web servers that implemented secure connections after the revelation from Snowden but some polls saw a significant increase in adoption of HTTPS to help protect users.[1] The introduction of tools, such as Let’s Encrpt which launched in 2016, certainly helped to bolster the number of websites that supported HTTPS but many of these solutions didn’t address server-to-server connections or e-mail connections.
Fast forward to today, a new set of standards have been put in place to help protect e-mail, both while in transit (between the client and server as well as between servers) and while the email is sitting on the server. It’s not exactly easy to understand how many of these "new" technologies work together or exactly how they protect your data. There are many resources on the Internet to explain them to you; lets add another.
Securing the mail connections
It’s important to remember that when e-mail was first developed back in 1973 (RFC561) that just making it work was the important part. There were no such things as untrusted networks; if you were on the network then you were known by others. Security wasn’t a thought as the circle of users was so small and the networks were manually controlled. Now it would be a huge undertaking to change the basic structure that is e-mail that it would actually be easier to break things rather than try to fix everything at once.
Some of the new protocols that help add security include Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), Domain-based Message Authentication, Reporting, and Conformance (DMARC), SMTP MTA Strict Transport Security (MTA-STS), and SMTP TLS Reporting (TLS RPT).
The first group, SPF, DKIM, and DMARC, exist to help authenticate e-mail as have been legitimately sent from an authorized user and authorized server for a particular domain. This helps mostly with SPAM but can also be good for protecting yourself against someone who might try to spoof a message as something you sent when you actually didn’t.
The second group, MTA_STS and TLS RPT, are all about enforcing encrypted connections between e-mail servers, preventing an adversary from being able to downgrade a connection to plaintext, since that is the default in e-mail connections.
Sender Policy Framework (SPF)
SPF is an advertisement to other mail servers which includes IP addresses authorized to send mail on behalf of a domain and what to do with mail that is received outside of this policy. This works well to prevent spoofing of e-mail from an unauthorized source. When properly implemented, this policy secures the mail coming from your domain as other servers receiving mail outside of this policy will either quarantine (move to junk mail) or flat out reject the incoming message. Similarly, it also helps protect you from spoofed mail addressed to someone on your domain.
The policy is defined in DNS as a TXT record.
DomainKeys Identified Mail (DKIM)
DKIM was sort of rolled out in parallel with SPF and adds a digital signature to each e-mail sent from a mail server. The incoming e-mail server should be able to cryptographically verify that the message came from the proper server as well as validate that the message wasn’t changed in transit.
DKIM is a little more difficult to setup as it requires a key pair (public and private) be setup for each domain and a DNS record advertising the public key.
Similarly to SPF, a properly setup mail server can take action on a message that doesn’t have the proper signature and reject the message outright.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DMARC was put in place to basically stitch together both SPF and DKIM. Now an incoming e-mail server can verify both the SPF policy and the DKIM signatures and make a decision on what to do with the message based on the DMARC policy. Yep, there’s a policy for the policy. But DMARC added a very important feature to both SPF and DKIM: feedback.
Once an e-mail server has verified (or not) an incoming message as being authentic, the DMARC policy tells the server to, on occasion, send feedback to the originating domain to let them know if all messages received were from an authenticated source and, if not, where the messages were coming from.
Now we have authenticated mail that, when setup properly, cannot be spoofed (or at least it’s much more difficult). But what about encrypting our messages to make sure they can’t be easily read in transit.
SMTP MTA Strict Transport Security (MTA-STS)
The MTA-STS policy tells other e-mail servers that want to connect up to your e-mail server whether it should be an encrypted connection or not. It also tells the other e-mail server what servers it should use when sending mail to your domain.
|
Note
|
You will need have your e-mail server (SMTP) setup to use TLS with a certificate prior to setting up MTA-STS and TLS RPT. |
This prevents a couple different attacks. First, it tells the distant e-mail server that, yes, you want all connections to your e-mail server to be encrypted. If you cannot make an encrypted connection (known as a downgrade attack), then just stop and retry later. Second, if the attacker can’t break the encryption, perhaps they can make a fake e-mail server for the distant end to connect to and then can read the messages before passing them along to your e-mail server as if it came from the first (this is known as a man-in-the-middle attack). This is prevented by the listing of servers in the policy.
The MTA-STS policy is stored on a server designated by your domain and is referenced by a DNS record to tie things together.
SMTP TLS Reporting (TLS RPT)
Much like DMARC, TLS RPT provides that feedback loop for other servers to use to tell you whether or not there have been any problems with securely connecting to your e-mail server. This record is stored in DNS.
|
Important
|
Since much of this security is being retrieved from your DNS records, the use of Domain Name System Security Extensions (DNSSEC) is really needed here. |
With these five protocols in place, your e-mail server (as well as the ones you communicate with) have improved its confidentiality and integrity protections for data flowing both within your domain as well as between domains. And while it’s important to setup all of these solutions, just getting started with one or two of them will dramatically improve the security of your e-mail. All of the information regarding who the message is going to, from, and the contents of the message are now protected while being moved around between servers.
Of course, this doesn’t protect data at rest (those pesky e-mails that are just sitting around on a server waiting to be read or otherwise dealt with). The use of OpenPGP (the open source implementation of PGP) is still important to protect the contents of your e-mail. Anyone that can access your data as it sits on the server can read everything as it is usually stored in plaintext. There is an exception to this, however. E-mail providers such as ProtonMail, Hushmail, Mailfence, and Tutanota also encrypt your mail while it is on their server. This means that only you can read your mail.[2] Oh, and don’t be fooled by the encryption feature that Google’s Gmail recently rolled out. This does not prevent Google from being able to read your mail. Remember, it is their job to read your mail so they aren’t going to support technologies that prevent that.
Perhaps one of the safest ways to manage your data is to do it yourself, but that can have technical challenges. Even with all the policies and security protocols in place, much of this is left up to trusting a third-party with your data. But, this is all about improving your security and reducing your attack area. With the networks secure, there are much fewer ways that someone could gain access to your data.[3]
Lastly, it’s important to audit your security once you have it setup. There are several tools available to help verify that your settings are correct and even help manage the reports you receive from other servers. Mailhardener is one that I use which has a free tier for personal use and even has a knowledgebase to help you setup these technologies.[4]