Securing Email for an Organization

It might seem odd at first to preface an article on email security with a history lesson. Ultimately though, understanding the primary problem email was designed to solve, and the fact that security was loosely bolted on after-the-fact in tiny bursts over many decades, helps tremendously in understanding the landscape. In the 1970s and 1980s, a protocol suite named “UUCP” (Unix-to-Unix Copy) was all the rage (https://en.wikipedia.org/wiki/UUCP). At this time, the only people with an internet connection were academics at large universities and government officials. UUCP’s email protocol leveraged something called a “bang path” to send a communication from one computer to another. Nothing was centralized, and you had to know the complete path between hops to send a communication in the least expensive way. There were handful of nodes that people operated that served as “common” traversal points, and they would publish a list of those common nodes to their own computer systems. The sender would hopefully know a path from their system, to the common node, and combine it with the published path to determine what series of computer systems to send mail to. An example of a bang address would be something like this:

When analyzing this with a modern slant, this is a catastrophe waiting to happen. Anyone with access to any of those computers in between could read any communication. However, the mere idea of sending something sensitive over a computer system was laughable. Passwords weren’t yet common. In the tightly knit community of mostly stuffy academics, nobody had even considered the possibility of malice. It wasn’t until the Morris Worm in 1988 (https://en.wikipedia.org/wiki/Morris_worm), which was largely accidental, that the landscape shifted and people started to discuss security.

SMTP is the successor to UUCP for sending email, and the email address format we’re all familiar with ([email protected]) is the replacement for bang paths. No longer did people have to get out a notebook to make calculations. Instead, the domain portion of the email is used to lookup an MX record in DNS. This MX record publishes an A record, resolvable to an IP where an email client can craft an email that will be delivered to a particular recipient. This was an enormous feat at the time. No longer did you literally need a Ph.D. in order to send an email. SMTP, however, to this day pays homage to UUCP. The protocol does not create a connection between two endpoints the way HTTPS does. Instead, it’s still a series of hops from point A to point B. When you send an email, it might traverse 50 servers before it reaches its destination. SMTP alone did not introduce security into the model.

Years later, SSL came onto the scene (later to be replaced by TLS in the 1990s). SSL was a game changer, because it provided a standard way of wrapping an insecure protocol inside of a secure tunnel. In the case of email, this means encryption in-flight (but not encryption at-rest). In the case of HTTP, where only two parts of a transaction exist, encryption-in-flight is enough to be safe in the fact that your communication was not modified in transit. In the case of email, because it traverses so many different servers, it is not. Even if your email is encrypted between you and the first hop it takes, there is no guarantee that every hop between that node and the final destination simply sends the message in the clear to its next hop.

There are a number of competing ways to deal with this insecurity used today. One is to PGP encrypt a message before sending it out over email at all (encryption-at-rest). Once the entire contents of the message are encrypted, if it is modified, the recipient will not be able to decrypt it at all. An attacker who gets access to those data will not be able to read it. This is an extremely secure way to send an email but means that you have to either have previously communicated a shared-secret with the recipient using a totally separate secure channel or use asymmetric encryption and public keys trusted by a mutually trusted third party (like a certificate authority). In a way, this harkens back to UUCP. The barrier of entry to send an email is very high.

Because of the complexity of this solution, a more common strategy for many businesses is to only use email to send a link to an HTTPS web portal where customers can perform transactions. By limiting what is sent over email, security can be achieved by chaining your business process to the more secure HTTPS protocol. This is largely the easiest method for a lot of companies. It’s as easy as purchasing a “secure email gateway” and securing it with a publicly trusted SSL/TLS certificate (https://www.ssltrust.com.au/ssl-certificates).

What about emails your company is receiving though? You cannot control how another organization you wish to do business with handles their information, but there are things which you can do in order to mitigate risk. One of the biggest risks to a business today is spoofed email. An email consists of two different “FROM” addresses. The first is referred to as the “Envelope From.” It is contained only in the email’s message header and provides an email client with a return address for replies to the email. The other is the “header from,” which is actually what’s in the From: field of the email message itself. Both of these are easily spoofed. Spoofing the “envelope from” is just as easy as writing someone else’s address on the upper left of a letter. Spoofing the “header from” is just as easy as writing a letter and signing it with someone else’s name. A technology called “SPF” (sender policy framework) helps mitigate this risk. Companies choosing to participate with SPF publish a record of type TXT at the root of their domain, allowing an inbound mail server to perform a DNS lookup of the “envelope from” and comparing it to the list of approved sender domains published in the SPF record for that domain. The inbound mail server can use this information to decide if the email is likely spam or a phishing attempt. Unfortunately, it does not do anything to mitigate spoofing of the “header from” address. Replies will be sent to the real address in the “envelope from,” but this is still a powerful attack vector to get your users to click links in emails which can lead to compromise. User training is the biggest way to protect against this particular risk. Never send confidential documents over email. Mail administrators can setup special rules in their mail infrastructure to “tag” messages whose “header from” does not match their “envelope from” before it reaches the end user. Another popular strategy is for the mail administrator to tag messages claiming to be from an internal server but come from outside their network.

DKIM is a complementary technology concerned with whether or not emails are modified in-transit. DKIM-enabled domains publish (again through a TXT record) a public key. They then configure outbound emails to calculate an HMAC (a hash or “digest” of the message body, encrypted with a digital signature using the private portion of the key). Receiving email servers or clients who choose to verify DKIM can then calculate their own message digest. If it matches the decrypted digest (using the public portion of the key published in DNS), they know that the message was not altered in transit.

DMARC is a further step a company can take to protect their reputation. A third TXT record, DMARC, allows for communicating how SPF and DKIM failures should be handled. A company can publish an email address to receive compliance reports and request how seriously an organization takes failure of their policy. (The receiving email server can still be configured to ignore this request though. Some would argue this is poor “netiquette,” but it is understandable why companies in certain industries would rather all mail from incorrectly configured email servers.)

Ultimately, email was never designed as a secure protocol, and despite many attempts to mitigate risk over the years, there will always be residual risk as far as email is concerned. SPF, DKIM, and DMARC are not silver bullets, and they introduce a tremendous amount of complexity for only moderate gains. For businesses that are in a position to be trendsetters, the best strategy is still to rely on secure email gateways that direct users to transact over an HTTPS portal. To the savvy business leader, this should be seen not as a downside but as an opportunity to improve the user experience, provide consistent branding, and protect employees by simply teaching them to verify anything at all sent by email.

About the Author:

Paul Baka come with over 10 years-experience as a web security specialist, Paul has worked on a large number of projects for clients to better enhance their security practices and strengthen their security procedures.

From building his own software, tools and websites he has become proficient in a number of coding languages. He currently works at Keyko Pty Ltd as an Account Manager. Keyko is an Australian based company that specializes in web and email security.

In his spare time, he can be found pulling apart hardware devices to see how they work or hacking together scripts to try get apps to do more than they were originally intended.