Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

6/27/2019
03:48 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Inside MLS, the New Protocol for Secure Enterprise Messaging

As personal messaging platforms see the rise of end-to-end encryption, businesses struggle to provide strong levels of security.

As the world moves toward end-to-end encryption for personal messaging platforms, businesses are challenged to integrate the same level of security in corporate messaging apps.

Even encryption protocols for person-to-person messaging are still undergoing development. Services want to reduce the amount of sensitive data they store; however, only a few encryption protocols – Signal, for one – have been scrutinized for security.

The Signal protocol, which rolled out to WhatsApp's base of one billion users in 2016, is the first end-to-end encryption protocol to be globally deployed. Security guarantees of the open-source protocol include forward-secrecy and recovery from key compromise. And while a few personal messaging systems have adopted Signal, corporate messaging has failed to follow.

"In the consumer space there are a few services with end-to-end encryption but in the business space it's very rare," says Raphael Robert, head of security at Wire, which launched in 2014 as a secure messenger primarily built for consumers. Since then, it has repositioned itself to build a secure business collaboration system. Wire is currently in the midst of working to develop Messaging Layer Security (MLS), a new protocol designed to facilitate more secure enterprise messaging platforms.

Technical challenges often hold companies back from adopting end-to-end encryption. "The bigger the organization, the harder it is to make a change in general," says Robert. Scalability is a key problem: WhatsApp, for example, uses a protocol dubbed Sender-Keys to support group chats. The problem is, the protocol doesn't support post-compromise-security, meaning in a simple deployment an employee who left the company may still read messages.

In many modern enterprise environments, products use transport encryption between client and server but messages and content being shared aren't encrypted on the server. This information usually ends up in a large database, he continues, where it's vulnerable to third-party access. A cybercriminal needs only an employee's credentials to break in and get it.

"This is a huge risk, which doesn't really meet the requirements of businesses in general," he adds. "There is typically very sensitive information."

Messaging Layer Security (MLS): A New Protective Protocol

To address the many issues in enterprise messaging security, the Internet Engineering Task Force (IETF) is building the MLS group messaging protocol. Its goals for MLS differ from those of pairwise protocols: it aims to allow practical groups up to 50,000 clients, cover multiple industry use cases including federation and Web browser support, and offer formal security guarantees.

When Wire introduced end-to-end encryption to its system in 2016 and open-sourced its code base, secure messaging protocols were "always a big issue," says Robert. There was no open standard they could adopt. That summer, during the IETF meeting in Berlin, Wire proposed a standard that was protected by modern security properties and could be used by companies large and small.

MLS has since been undergoing development. While initiated by Wire, along with Mozilla and Cisco, in 2016, it has received support from major tech companies along the way: Facebook, Google, INRIA, and Twitter have all contributed to the effort. "In the past 18 months we've worked a lot on the core protocol to make sure of what kind of security guarantees we want to achieve and how we can achieve them," says Robert. Now, they're finalizing it for the academic community to review.

How will it be different? Researchers proposed it should be possible to use MLS in a federated environment, meaning you don't need a central server or central cloud to implement it. Employees should be able to communicate across clouds and devices, Robert explains.

Many businesses also struggle with the risk of shadow IT, he continues. People rely on their mobile apps to communicate internally and externally, and it's difficult to regulate. Most employees use multiple devices, which most existing protocols "never really took into account," he adds. Since its inception, the people behind MLS wanted to address security across devices.

"One of the core goals of MLS was to support multi-device scenarios and support groups, particularly large groups, and to make encryption as efficient as possible," he adds. With many protocols, encryption for groups can get expensive.

By next year, he hopes, MLS will be ready to integrate into messaging platforms. Robert, along with INRIA's Benjamin Beurdouche and independent researcher Katriel Cohn Gordon, will discuss the research behind, and details of, MLS this summer at Black Hat USA in a briefing entitled "Messaging Layer Security: Towards a New Layer of Secure Group Messaging."

Related Content:

 

 Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
tdsan
50%
50%
tdsan,
User Rank: Ninja
6/30/2019 | 6:09:35 PM
Not sure what we don't use IPv6 and the real reason this protocol is being developed
I think the real reason behind this is because they don't want the feds reading their emails.
Technical challenges often hold companies back from adopting end-to-end encryption. "The bigger the organization, the harder it is to make a change in general," says Robert. Scalability is a key problem: WhatsApp, for example, uses a protocol dubbed Sender-Keys to support group chats. The problem is, the protocol doesn't support post-compromise-security, meaning in a simple deployment an employee who left the company may still read messages.

I am not sure why we are not utilizing one of the best transport mechanisms on earth (IPv6), we have not even began to leverage all of its capability:
  • Protection against man in the middle attacks
  • IPv6 AES256 ESP/AH VPN capabilities
  • Faster transport mechanisms and improved processing of packets (faster transport speeds)
  • Tunnel capabiltieis of from 6-to-4 and 4-to-6
  • 17 quintillion addresses (an IP address for every grain of sand)
  • Ability to transport data across MPLS/IP networks at faster speeds
  • Authenticate and Encapsulate security packets across the network
  • Integrates with IS-IS (Intermediate-Systems/Intermediate-Systems) to run both protocols like ships in the night

Identify which users are trying to access which system because it uses a 1 to 1 connection instead of using multiple hop count (determine where the attack took place). We could encrypt the data packet from end to end.

Link "IPv6 Benefits"
Security
IPSec, which provides confidentiality, authentication and data integrity, is baked into in IPv6. Because of their potential to carry malware, IPv4 ICMP packets are often blocked by corporate firewalls, but ICMPv6, the implementation of the Internet Control Message Protocol for IPv6, may be permitted because IPSec can be applied to the ICMPv6 packets.

If malware is carried, we can employ Authenticated headers to ensure the data packets are sent only after it is considered a viable connection or limit the ability of others to connect to the network
ip6tables -I INPUT 1 -p tcp -m multiport -s 2606:a000:111f:efd::/64 -d 2606:a000:111f:efd::/64 --dport 22,25,80,443 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT # Logs the connections with SSH and web traffic
Todd S, Enterprise Architect
ITOTS Networks, LLC
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/14/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-6164
PUBLISHED: 2020-07-15
In SilverStripe through 4.5.0, a specific URL path configured by default through the silverstripe/framework module can be used to disclose the fact that a domain is hosting a Silverstripe application. There is no disclosure of the specific version. The functionality on this URL path is limited to ex...
CVE-2020-6165
PUBLISHED: 2020-07-15
SilverStripe 4.5.0 allows attackers to read certain records that should not have been placed into a result set. This affects silverstripe/recipe-cms. The automatic permission-checking mechanism in the silverstripe/graphql module does not provide complete protection against lists that are limited (e....
CVE-2020-8958
PUBLISHED: 2020-07-15
Guangzhou 1GE ONU V2801RW 1.9.1-181203 through 2.9.0-181024 and V2804RGW 1.9.1-181203 through 2.9.0-181024 devices allow remote attackers to execute arbitrary OS commands via shell metacharacters in the boaform/admin/formPing Dest IP Address field.
CVE-2020-9309
PUBLISHED: 2020-07-15
Silverstripe CMS through 4.5 can be susceptible to script execution from malicious upload contents under allowed file extensions (for example HTML code in a TXT file). When these files are stored as protected or draft files, the MIME detection can cause browsers to execute the file contents. Uploads...
CVE-2020-9311
PUBLISHED: 2020-07-15
In SilverStripe through 4.5, malicious users with a valid Silverstripe CMS login (usually CMS access) can craft profile information which can lead to XSS for other users through specially crafted login form URLs.