Many, many software service sales professionals throw around security phrases to make cyber security 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 to catch all for security, TLS, 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,” remarks Steve Anderson, an insurance technology expert & LinkedIn influencer with more than 330 thousand followers.
First, what is TLS?
TLS stands for transport layer security. This is a means, in short, of encrypting communications between two participating devices. This is mainly used when you communicate from your web browser to a web server. It’s simple for the browser to display “insecure” connections, pop-up warnings, or disable a page display.
But, with email, there are more challenges.
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, etc.) by default.
Sounds secure, right? Maybe not.
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 seen “only” by that recipient has been an afterthought.
Enter Opportunistic TLS. Here, the sending server, Gmail in this example, tries to send first with a secure TLS email transmission (SMTP) if the “opportunity” presents itself, and second, if it cannot send securely, it reverts to less secure or insecure transmission, automatic, and invisibly.
Sounds pretty good; everyone receiving email surely has the same mindset, and will accept email from Gmail through a secure connection, right?
Wrong.
According to the Gmail transparency report, continuously updated as of today, 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 you may send or receive via Gmail simply go out without any security. This is likely similar with Office 365 hosted email.
You might think, well, 1 in 10 insecure isn’t bad. However, consider it could be far worse.
According to the above report, for many recipient email domains, like Charter.net in the USA, Bigpond in Australia, Videotron via Bell in Canada; email to and from these domains to Gmail are never encrypted (0%) and with companies like Amazon, 57% are secured. What about the gazillion smaller companies out there? Do they have better security than Amazon?
And, it gets worse. Here is the big fallacy.
None of these transparency reports make the distinction which of the many TLS connections are considered insecure TLS. Generally, there are versions of with varying security; TLS 1.0, TLS 1.1, TLS 1.2, and now TLS 1.3.
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 for more than a decade; but use 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) plus 15% sent with a version of TLS with known security issues. Now you have an issue with 25% of your email (1 in 4 emails), at the very least. If you communicate with customers in smaller companies, individuals, the percentage is likely higher.
The problem is, what to do?
Microsoft states 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). 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.
Bottom line:
1. Microsoft Office 365, G-suite, and other “Opportunistic TLS” systems likely send at least 25% of email with no security or in an insecure, less than a (privacy) compliant manner.
2. There is no easy fix for these systems, as their option (as 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 insecure rather than not at all.
What to do: Opportunistic TLS with Auto-Fallback
Add on to Gmail, Office 365, Zimbra, or any email, a simple to use service that, if no TLS is available, or an insecure version of TLS is in place, the communication automatically reverts to an alternative method of email transmission encryption; dynamically and without bothering or burdening sender or receiver.
“RMail consistently makes email life easier for business people. Easy, secure, simple, automatic,” adds Anderson. “And, RMail Security Gateway is just another way that RPost does it. RMail Security Gateway is a great option for total encryption automation.”
Find More:
Install RMail onto your existing email program or security gateway, as it has the simplest form of automatic encryption, using secure versions of TLS when available, and when not, reverting to AES 256-bit PDF encryption. The recipient either can view the message received security right in their email program or view it in a PDF if required to maintain security and compliance.
Try RMail at no cost, with no credit card needed (click for your Gmail or Outlook RMail app).
CLICK HERE if you are interested in following RPost from an investor perspective through its investor relations emails and briefings.
To learn more visit www.rmail.com.
December 03, 2024
November 29, 2024
November 20, 2024
November 12, 2024
November 06, 2024