Real-world email security: is TLS encryption the answer?

In the search for a comprehensive email encryption solution, organisations can often find that they have to make a trade-off between user-friendliness and effectiveness:

Traditional message encryption protocols such as PGP have often thrown up barriers for both sender and recipient. They remain too technical and complex for the average user, resulting in potentially low adoption rates.

TLS secure email or Transport Layer Security (TLS) is the other side of the coin. While technically user-friendly – indeed it requires almost no user interaction for the sender at least – its effectiveness and levels of assurance are lacking, especially for organisations needing to secure data as it leaves their organisation.

TLS email in operation

TLS is a cryptographic protocol that provides privacy and security between computer systems communicating over a network. Utilising public and private key encryption, TLS sets up a secure transport link between email servers on the Simple Mail Transfer Protocol (SMTP). When the encryption keys are shared between the sender and recipient servers, TLS also involves the optional sharing of digital certificates.

Since it’s already available on most mail servers and hosting providers, TLS has long been judged the ideal solution to email encryption.

Public key encryption and certificate authentication obviously provide some level of security and assurance. However, vulnerabilities when using TLS email encryption quickly become exposed when considering the current level and sophistication of cyber threats.

Reliance on DNS

As TLS functions alongside the SMTP, it also uses the Domain Name System (DNS) to look up the required recipient email server when attempting to deliver an email. DNS has well-known weaknesses that can be exploited, including the classic DNS spoof. In this instance, an attacker sits between the sending server and the internet, intercepting communications with no way for the sender to know it’s happening.

Of course, if digital certificate validation was required, this wouldn’t be such a problem. However, this is usually not the case. With the large-scale adoption of hosted email services, the ability to conduct accurate DNS name validation and certificate validation becomes a significant hurdle. Name mismatches are often allowed and email messages are permitted to be delivered.

Here’s an example to illustrate this point. If ABC Inc. (abc.com) employs the services of a third-party anti-malware service (e.g. mailservice.com), the third party will host their MX email record (a DNS resource that specifies a mail server responsible for accepting email messages on behalf of abc.com). When a server attempts to send an email to bob@abc.com it will request the email server location via DNS. DNS will return a list of servers (e.g. mail1.mailservice.com) that have no reference to the abc.com domain. To ensure email is delivered, the sending server will by default ignore the domain name and associated certificate mismatch.

So, again, the confidence in the security isn’t there.

Lack of auditing

Another significant limitation of TLS email encryption is the lack of easily accessible auditing or proof of transmission. If an email is delivered to a non-verified server or is sent in plaintext, there is no sender notification and no easily accessible audit trail for system administrators to access. Being able to quickly identify and remedy IT security failures is crucial in the defence against modern network attacks and yet TLS does not provide the auditing capabilities to do so.

TLS fails open

TLS is intended to ‘fail open’ in the event of send failure, rather than ‘failing safe’ (whereby if errors occur, the email fails to send at all). Thus in the event of failure, TLS falls back to regular SMTP and messages are sent in clear text.

The reason for the fail open design is that email delivery has always been perceived as more important than the security and confidentiality of the messages being delivered; users do not accept non-delivery.

However, attackers can exploit this design by triggering a fail open error to intercept email. This level of ad hoc security should simply not be acceptable for most organisations: Is there a third way between fail open security and non-delivery of email?

User-friendly and secure: An alternative mechanism for email encryption

It’s important to note that, when it works, TLS is a great way to augment message-level security. Nevertheless, in today’s cloud-based and cyber-security aware world, solely relying on TLS to send encrypted emails is asking for trouble.

The Egress Switch philosophy is to provide real security for the real world:

• Usability is not just about how easy it is to use the email encryption solution. It’s about helping users make good decisions when it comes to sharing data, educating whilst providing the safety net required for genuine assurance
• Employing message-level encryption means that emails get delivered but the sender always remains in control (the perfect blend of ensuring messages are sent, whilst never compromising on security)
• Switch encrypted emails never fail open. They are not susceptible to DNS spoofing and other historic hacking methods – even if a mail server is compromised, the message remains encrypted.
• Essential, comprehensive auditing logs enable IT administrators to monitor the mail flow in and out of their organisation, including the classification labels and encryption security used.