22.05.2019

Solving the encryption issue with TLS 1.2

Many, many software service sales professionals throw around security phrases to make cybersecurity sound simple. Today, as technologies advance and threats get ever more sophisticated, encrypting email for privacy compliance is not getting simpler. The devil (hacker) is in the details. Here, we will try to (in a simple manner) decipher a commonly referred catch-all term for security, TLS encryption and especially TLS 1.2 and explain why the details are important. 

“Not all TLS is created equal. Not all email one thinks is going by TLS, in fact is transmitted securely"

- Steve Anderson, an insurance technology expert & LinkedIn influencer. 
This article investigates the background of the above statement. 

First, what is TLS encryption?

TLS stands for transport layer security. This is a method, in short, of encrypting communications between two participating devices. It is mainly used when people communicate from their web browser to a web server (displayed as the “green lock”). It is simple for the browser to display “insecure” connections, pop-up warnings, or to disable a page display.

Challenges with secure email communication

Sure, if you log-in to Gmail via your Chrome browser, the connection from your device to the Google email server is secured this way. But what about the email after you hit send, when it leaves Google’s Gmail server onward to the recipient? This is where “Opportunistic TLS” may or may not be used. It is used with many major email providers (Microsoft Hosted Exchange Office 365, Gmail, 1&1, etc.) by default.

Secure or not secure?

Let’s first remind ourselves of the most important part of email for MOST users — that it gets to the intended recipient. Traditionally, whether it is seen “only” by that required recipient has been an afterthought.
Enter opportunistic TLS. Here, the sending server, Gmail in this example, tries first to send with a secure TLS email transmission (SMTP) if the “opportunity” presents itself, and second, if it cannot send securely, it reverts to a less secure or insecure transmission, automatically and invisibly. 

In a nutshell: Everyone receiving emails surely has the same mindset and will accept email from Gmail through a secure connection, right? Wrong. 

According to the Gmail transparency report, 88% to 91% of inbound and outbound email to and from Gmail are sent using TLS. This means, typically, more than 10% is sent and received without any security. So, 1 in 10 messages senders may send or receive via Gmail simply go out without security.

The issue

None of these transparency reports make the distinction which of the many TLS transport connections are considered insecure. Generally, there are versions with varying security; TLS 1.0, TLS 1.1, TLS 1.2 and now TLS 1.3. More and more European countries publish recommendations or regulations to force a specific TLS level to avoid opportunistic TLS or even an unencrypted delivery. We have already seen such regulations in Denmark, Germany and Switzerland.

Focusing on TLS 1.0, there are known risks. In particular, a TLS downgrade attack. In short, a hacker can intercept the TLS 1.0 check preceding the server to server communication to trick the sending server into sending the message in an insecure manner. Security professionals have been trying to get IT administrators to upgrade from TLS 1.0 to TLS 1.2 for more than a decade; but usage of this still persists, en masse; and typically accounts for more than 15% of all TLS email connections. So, maybe you are at 10% sent insecure (no TLS connection) plus 15% sent with a TLS version with known security issues. Now you, as a sender, may have an issue with 25% of your emails (1 in 4 emails!), at the very least. If senders communicate with customers in smaller companies or individuals, the percentage is likely higher.

The way forward

Microsoft stated in a 2018 blog post, while they will no longer support TLS 1.0, “this does not mean Office 365 will block TLS 1.0 and 1.1 connections. There is no official date for disabling or removing TLS 1.0 and 1.1 in the TLS service for customer [email] connections.”

And, remember, TLS 1.0 is known as not compliant in some circles (i.e. PCI financial compliance standard, Swiss Customs Agency etc.). What about for HIPAA, PII, NPI? GDPR privacy compliance? If there are known vulnerabilities with TLS 1.0, one would believe they may not be considered a “privacy compliant” means of transmission. Time will tell.

The Information Commissioner's Office (ICO) in Great Britain already recommends the use of TLS 1.2 as a secure transport method for email communication.

Solution: Forced TLS level with auto-fallback

Frama RMail, as an add-on to Gmail, Office 365, Zimbra or any email provider, is a simple to use service. If no TLS connection is available or an insecure TLS version is in place, the RMail add-on automatically reverts the communication to an alternative method of email transmission encryption; dynamically and without bothering or burdening sender or receiver. Frama RMail now forces secure versions of TLS transport when available, and when not, it will revert to AES 256-bit PDF encryption. The recipient either can view the message received securely directly in their email program or view it in a PDF if required to maintain security and compliance.

Frama RMail now supports forced TLS connection based on TLS 1.2. Senders can now force their email delivery to TLS 1.2 for compliance and if TLS1.2 is not available use SecurePDF fallback to maintain compliance and data protection.

Verdict

  1. Microsoft Office 365, Gmail, and other “opportunistic TLS” systems likely send at least 25% of email with no security or in an insecure, less (privacy) compliant manner.
  2. There is no easy fix for these systems, as their option (which Microsoft points out as not desirable) would be to not deliver the email at all; which would cause chaos for senders and receivers. It appears, from their blog post, they prefer to delivery insecurely rather than not at all.
  3. Frama RMail for Outlook and Gmail now support forced TLS based on TLS 1.2 connections to ensure compliance and data protection worldwide. 

    This article was written in partnership with Zafar Khan, CEO RPost Inc.

Contact us

  • Frama RMail TLS 1.2