Why TLS May Not Be Enough for Your Email Encryption Strategy
The digital age has revolutionized how we live our lives as well as how businesses operate. Businesses today ultimately enjoy much greater engagement with their customers and clients. These companies also have lots more data at their disposal to better understand their business and their customers’ buying activity. This data enables businesses to close efficiency gaps, identify growth opportunities, and better serve their customers.
This data, unsurprisingly, is incredibly precious. Protecting it therefore has become critical to a business’s survival in a very competitive market. When organizations protect their personally identifiable information (PII), protected health information (PHI), intellectual property (IP), or other confidential information, they ensure business continuity, demonstrate compliance with data privacy regulations, and keep their reputations intact.
Businesses most protect their sensitive information whether it’s stored on servers or shared via email or other communication channel. Transport layer security (TLS) has become an important part of every organization’s email security strategy as they struggle to comply with regulations like the Payment Card Industry Data Security Standard (PCI DSS), the Health Insurance Portability and Accountability Act (HIPAA), and the European Union’s General Data Protection Regulation (GDPR).
Enabling TLS, however, won’t guarantee that your emails are safe from prying eyes. In fact, many organizations still use TLS incorrectly, which leaves their emails vulnerable to unauthorized access and data leaks.
How Does TLS Work?
In order for a website or application to use TLS, it must have a TLS certificate installed. A TLS certificate is issued to the person or business that owns a domain. The certificate contains important information about who owns the domain and the server’s public key, both of which are important for validating the server’s identity.
A TLS connection is initiated using a sequence known as the TLS handshake. Whenever someone visits a website that uses TLS, the TLS handshake begins between the user’s device (also known as the client device) and the web server.
During the TLS handshake, the user’s device and the web server:
- Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) to use,
- Decide which cipher suites to use,
- Authenticate the identity of the server using the server’s TLS certificate, and
- Generate session keys for encrypting messages between the user’s device and the web server after the handshake is complete.
What Is a Certificate Authority (CA)?
A certificate authority (CA) is an organization that acts to validate the identities of entities (e.g., websites, email addresses, companies, or individuals) and bind them to cryptographic keys by issuing electronic documents known as digital certificates.
A digital certificate provides the following:
- Authentication—serves as a credential to validate the identity of the entity it has been issued to
- Encryption—for secure communication over insecure networks
- The integrity of documents signed with the certificate so that a third party in transit cannot alter them
What Is the Difference Between TLS and SSL?
TLS evolved from a previous encryption protocol called secure sockets layer (SSL), developed by Netscape. TLS version 1.0 began development as SSL version 3.1, but the name of the protocol was changed before publication to indicate that it was no longer associated with Netscape. As a result, TLS and SSL are sometimes used interchangeably.
Potential Vulnerabilities With TLS
Although TLS and SSL undoubtedly form a vital foundation for any company’s approach to data security, they still contain vulnerabilities.
The main weakness arises from companies’ lack of understanding about email encryption, with many believing the transport channel, and thus the email, is fully secured whenever TLS is used.
Companies, however, need to remember that email messages travel between the sender and recipient’s email servers, a channel that includes hops outside their respective networks. An email is only protected until the next mail hop, and there is no possibility of controlling what happens to it once it reaches the next Simple Mail Transfer Protocol (SMTP) hop.
A confidential message therefore could be exposed inside the company’s network, as TLS does not provide end-to-end encryption. TLS only secures the channel from the sender’s device to the corporate mail server. But emails are often transferred via additional servers where encryption cannot be guaranteed.
For example, in the case of antivirus checking and content scanning, data can be exposed to nosy administrators or other employees on the way.
Another security risk lies in the X.509 certificates used. Many companies fail to validate their certificates, leaving all their sensitive data exposed.
Companies must ensure that certificates have been issued by a trustworthy and reputable certificate authority (CA). This is anything but trivial, as many companies sign their certificates themselves.
Firms also need to check whether certificates are valid and whether encryption algorithms and key lengths are current (read: state-of-the-art).
Many companies, especially those who use OpenSSL, create their own certificates, as it is convenient and more cost-effective than certificates from a proper CA. Yes, certificates cost money. They must be purchased and renewed. If companies forget to renew, the certificate is eventually revoked and companies must pay the CA (again) for a new certificate.
Companies are also often unaware that if they use an incorrect TLS version that does not deploy “perfect forward secrecy,” messages may be decrypted by unauthorized uses who discover the keys.
Another known TLS limitation is “optional TLS” system configuration. With “mandatory TLS,” the originating system will only transfer an email message if the next system in the chain supports TLS; the message will not be transferred if that system does not support TLS. If, however, a system employs “optional TLS,” it will transfer the message anyway, thus leaving the channel unencrypted and the message exposed.
Here are some additional reasons why TLS may be insufficient to secure your email communications.
TLS defends emails from some, but not all, types of attacks
TLS by itself is not sufficient for email security, as it only protects against some forms of email attacks. TLS is particularly effective against man-in-the-middle and eavesdropping attacks, which occur while data is in transit. If you have sensitive information stored on your servers or databases, you need to use an additional encryption protocol like Pretty Good Privacy (PGP) or Secure/Multipurpose Internet Mail Extensions (S/MIME).
These encryption protocols will ensure that if a hacker gains access to the server, they will not be able to read the encrypted data. And because these protocols don’t rely on sending plaintext over the wire, they’re less susceptible to traffic analysis and other side-channel attacks that monitor encrypted communication streams.
TLS can be vulnerable to downgrade attacks
TLS is typically used to secure connections between your computer and a server, like when you log into your email using a browser. But it can also be used for other connections, like sending emails from one server to another.
The problem with this approach is that the entire connection isn’t encrypted. Only the data between the sending and receiving servers is encrypted—and those servers may not have strong security. A downgrade attack could intercept traffic on an unencrypted link and read messages as they go by. Unless you have end-to-end encryption, you could be putting your data and your organization at risk.
TLS needs a stronger handshake
TLS is the most common encryption protocol used today, but it still has limitations. To ensure your company’s email is secure and encrypted from the start, use STARTTLS with encryption algorithms such as PGP or S/MIME.
This way, even if someone intercepts your emails in transit, they’ll be unable to read them without your private key. It also makes it more difficult for a man-in-the-middle attack to take place by having an extra layer of encryption on top of the initial TLS handshake.
If you have confidential information that needs to be transmitted securely, look into adding another layer of protection by encrypting your email through a third-party service provider.
Kiteworks for End-to-End Security and Encryption
Kiteworks is more than a secure email provider. It serves as a private content network (PCN) for governance, compliance, and security related to sending and receiving sensitive content into, through, and out of an organization.
Kiteworks provides enterprise-grade encryption and uniform security controls via an email encryption gateway and a Microsoft Outlook plugin, web application, enterprise application plugin, or mobile application. It also delivers role-based policy automation to ensure the security and compliance of an organization’s most sensitive information.
Schedule a personalized demo to learn how Kiteworks automates sending and receiving emails that contain confidential information, regardless of the encryption standard used.
Blog Post:
