There are a variety of different types of encryption that can be used to secure email, with some far more effective than others. A lot of messaging technology that has been invented recently uses end-to-end encryption, but most emails are not sent like this. A typical email provider relies on the Simple Mail Transfer Protocol (SMTP) to encrypt emails during transmission, often using Transport Layer Security (TLS). Let’s take a look at how this works in practice.
What is opportunistic TLS?
The standard form of TLS is called “opportunistic TLS”, and it works by securing email wherever possible. Opportunistic TLS uses an extension called STARTTLS to send a request from the sender’s server to the recipient’s server. This initiates a handshake protocol to create the conditions necessary to exchange encryption keys and establish an encrypted tunnel that ensures the email is sent safely and securely.
Where the target mail server does not support TLS, however, using opportunistic TLS, the sender’s server will use an unencrypted channel to deliver the email and prioritize delivery.
As a method of encryption, opportunistic TLS is suitable for a world where usability and expedience are the priorities of email users. It means accepting the elevated security risk of sending some emails unencrypted by reducing the chance of a message not being delivered.
Put simply: with opportunistic TLS, delivery is more important than security.
What is forced TLS?
Another configuration of TLS for email encryption is “forced TLS”, which places a higher priority on security. Servers using forced TLS will also seek to establish an encrypted tunnel that sends a message securely, but in cases where this is not possible, these servers will not resort to sending the email unencrypted. With forced TLS, the email can only be sent when a recipient email domain is authenticated as a trusted source. If the secure tunnel can’t be established, the email simply won’t be sent at all.
Security is given higher priority in forced TLS, and users accept the elevated chance that a message will not be delivered in return for a reduced risk of an email being intercepted. Enabling forced TLS requires creating IT rules and policies, as well as running PowerShell scripts and tweaking configurations. It is typically used for communication between institutions, rather than in more open-ended email exchanges with customers, friends or small organizations.
Put simply: with forced TLS, security is more important than delivery.
How does opportunistic TLS work?
Let’s consider an email sent from Sally to Josh using opportunistic TLS. When sally@sender.com hits “Send”, her server issues a request to the server used by josh@recipient.com. When Josh’s server responds, this establishes a range of operational steps such as choosing protocol version, session ID and creating an initial random number to use in this specific TLS session for Sally’s email to Josh. It also establishes common security capabilities for the session. Finally, it allows for the exchange of digital certificates from Sally, Josh or both. Exchanging these digital signatures is optional, and Sally’s email can still be sent using opportunistic TLS without certificates.
Once these steps have been completed, it is possible for Sally and Josh’s servers to exchange encryption keys and allow for transport encryption. This handshake protocol establishes an encrypted tunnel that ensures Sally’s email is delivered securely. But if errors occur that prevent this process, opportunistic TLS will “fail open”, meaning the email will be sent in clear text, unencrypted.
Report
How does forced TLS work?
Forced TLS takes a similar approach, but with some important distinctions. Let’s look at how Will might send an email to Jasmine using forced TLS. Will is sending sensitive data that is being used in a research program from Will@lab.com to Jasmine@college.com. The IT teams at both organizations have taken the necessary steps to configure both email accounts to use forced TLS, and both Will and Jasmine are aware of this fact prior to the email being sent.
The process is similar to how opportunistic TLS works, but with one crucial distinction. Where an error occurs in any of the steps needed to ensure an encrypted tunnel, the email does not send. Rather than “fail open”, forced TLS opts for “fail safe”, prioritizing security over communication. Consequently, the email isn’t delivered.
Is forced TLS better than opportunistic TLS?
Both types of TLS have certain advantages in different data sharing scenarios and/or for different types of organizations. Users don’t need to take any additional security precautions when sending emails (such as applying encryption), and in the case of opportunistic TLS they can be confident that their email will arrive even if technical difficulties emerge. This offers security while prioritizing communication, keeping the world’s vast traffic of emails flowing. Failing open and prioritizing email delivery, however, can put data at risk of interception by cybercriminals, who are able to monitor email traffic on hacked servers.
Large organizations that require confidentiality can use forced TLS to create a secure and, again, low-friction method of communicating. This allows them to share data with other similar organizations who have also enabled forced TLS, providing additional protection to sensitive communication.
Because the TLS protocol has been around so long it is familiar within the IT world, and so the risks and benefits are well understood. Security and IT professionals can implement TLS and explain to their employers and colleagues what the benefits and risk of each are. Those who prefer guaranteed communication tend to opt for opportunistic TLS, while those who prize security will go with forced TLS. As is so often the case in the security industry, there is a trade-off between usability and security risks.
Unfortunately, these risks are also well documented. The TLS protocol was not designed for the ubiquity of email communications that we see today. It is not entirely secure, particularly opportunistic TLS given the “fail open” functionality. Not only does this expose data to being intercepted, the sender has no assurance whether the email is being sent by TLS or not. Sender’s don’t receive a notification within their email client verifying that TLS is properly enabled by the recipient, so a bit like throwing spaghetti at a wall, they will send the emails regardless and see where TLS “sticks”!
Forced TLS, meanwhile, is a rigid system that can be cumbersome to set up, and prevents users from communicating with recipients who do not use it, including most small organizations and all freemail accounts.
Where users are unable to use forced TLS, they may resort to alternative methods of communication, such as texting or even using their personal email addresses. This could create new security issues, as well as breach their organization’s security policy and create problems related to data regulation.
Additionally, once an email is sent using TLS there is no audit capability, making it impossible to restrict access or recall emails, as well as complicating any forensic efforts to pinpoint loss of data or leaks. Aside from secure transmission no other security measures are applied to the email, meaning the sender cannot control what a recipient can do with sensitive data that legally the sender/sender’s organization is the data owner of. This includes being unable to prevent actions such as forwarding emails to unauthorized recipients or printing attachments.
Is there a better type of encryption?
In the professional world, TLS is not secure enough to meet risk requirements around data sharing and compliance. This is especially true when it comes to securing data that is subject to additional regulatory standards, such as personally identifiable information. Email is the most common form of business communication and attackers know this, so many are using downgrade attacks to overpower opportunistic TLS, or man-in-the-middle attacks which can break the security on opportunistic and forced TLS.
Modern technology has moved on from TLS, and it is now possible to provide end-to-end encryption for emails at scale.
We built Egress Protect to prove that there does not need to be a trade-off between usability and security when it comes to the most important form of business communication. Egress Protect offers a much higher standard of security than TLS through end-to-end message-level encryption, along with features such as encrypted data at rest. It delivers security that is proportional to the level of risk. It is even possible to vary the level of confidentiality, preventing the saving or printing of email bodies or attachments by recipients. Every email provides a detailed audit log for improved security, and facilitates real-time email recall.
TLS was an excellent invention that provided a lot of additional security over an open protocol. But solutions like Egress Protect show that it is no longer fit for purpose in the modern workplace.
