After the Certified Information Systems Auditor’s (CISA) recent warning that two TeleMessage TM SGNL critical vulnerabilities were being actively exploited, stakeholders have taken notice.
US Federal Cybersecurity Agency strongly encouraged organizations to implement mitigations provided by vendors immediately, underlining the seriousness of these flaws.
In a discussion with , ICD, Kee Jeffreys, the co-founder and developer of Session – an open-source encrypted message app – said that the vulnerabilities in TM SGNL were due to multiple design and implementation mistakes, which undermined the security intended.
Decentralized messaging apps are growing due to a convergence: privacy concerns rising, distrust in Big Tech increasing, advancements in peer-to-peer technology and blockchain, as well as shifting regulatory environments.
Session is praised for its dedication to privacy and resistance to metadata, but some reviewers claim that Signal, another encrypted messaging service, strikes a better balance, combining robust privacy protocols with community-building, user-friendly features.
Jefferys stated that “in Session’s instance, it is built for users needing anonymity and resistance to metadata, even if this means making some trade-offs in terms of features or UX.”
The minister also spoke about the growing institutional interest for decentralized messaging platforms, and the reasons he thinks that in the future departments like national security or foreign service will be more likely to investigate these technologies. This is especially true when it comes to internal communication involving high-risk situations.
Excerpts:
CISA vulnerabilities found in TM SGNL
CISA Directive Highlights Vulnerabilities in TM SGNL. Why, according to you, are these vulnerabilities so serious despite end-to-end encrypted communication?
When implemented properly, end-to-end encrypted messages prevent anyone from outside of the conversation accessing user’s messages.
In the case of TM SGNL however, vulnerabilities were caused by multiple design and implementation mistakes, which undermined the security intended and resulted in “security theatre.”
It was not a single flaw but a series of bad design decisions which exposed the user’s data.
TM SGNL first created an unencrypted version of each message in a communication and stored it on a web server.
It is a highly appealing target for attackers because it creates a hive of data.
The server also made available a URL that anyone can use to download its current memory.
The server stores sensitive authentication information, such as weakly hashed user passwords, in its memory when it receives and processes these unencrypted emails.
These vulnerabilities combined allowed even a relatively inept attacker to download the server’s memory, obtain authentication data, compromise user accounts and read plaintext communications.
This example highlights a crucial point: the strength of secure protocols is only as good as code quality, infrastructure implementation and infrastructure design.
Decentralisation can reduce risk in a structural way
Invezz, you’ve said that the threat is a single vendor. How does decentralization reduce this risk structurally?
Absolutely. Even a small mistake could put all of us at risk when one company is in charge of everything including code, servers and updates.
Decentralization reduces the ability of a single server to compromise a network.
Session networks are not centralized, and there is no single entity that holds all messages.
The network is made up of nodes that are operated independently around the world, with the source code available to anyone.
Instead of depending on a single supplier’s trustworthiness, your system is designed to work without any trust.
What is the difference between Signal and Session?
Invezz Session, a decentralized messenger that is resistant to metadata and fully decentralized. What is the fundamental difference between your infrastructure and Signal or other encrypted applications?
Session differs from most messengers that still rely on central infrastructure.
Session is based on an onion routing network decentralized, inspired by Tor and specifically designed for messaging.
Session does not rely on central servers. Instead, it routes messages via a network of nodes operated by the community, which effectively hides users’ IP address from nodes that store their messages.
Session does not require you to provide a real-world identification such as a telephone number, an email address, or other identifiers.
Session does not send an audit log that is unencrypted of the communications between users to a server, unlike traditional TM SGNL.
Session use case, and efforts to continue improving usability
Invezz: Tech reviewers say that Session provides a high level of privacy, which is good for security, but Signal combines robust privacy policies and helpful community building features to appeal to a wider range of users. What is your opinion on this issue?
It’s fair to say that. Signal does a great job of making private messages feel seamless for users who don’t have privacy expertise.
Session is built to meet the needs of users that need privacy and resistance against metadata, even at the cost of some features or user experience.
Session does not ignore usability. Session contributors are working on improving UX by simplifying the technical jargon, and making it easier to start messaging, without worrying about technical details.
The institutional need for decentralised communication
ICD: Are you seeing a growing demand from institutions or enterprises for decentralized messages? What verticals have shown early success?
Absolutely. Journalists, lawyers, legal professionals and whistleblowers are all showing an increasing interest in Session.
Decentralized messaging is also being explored by some DAOs, privacy-focused startups and other DAOs.
Although it’s early in the game, there is a common theme: they want a strong infrastructure and privacy that does not have any single failure point or control.
Decentralization has become more important as regulations are tightened and the number of data breaches increases.
Decentralisation of messaging is likely in government branches such as national security/foreign service
Invezz Do You Believe Governments Will Ever Adopt Decentralized Messaging Protocols or Will They Remain Dependent on Vendors they Can Oversee?
It’s not easy. Naturally, governments prefer auditability and control. This often drives them to proprietary systems or those managed by vendors.
As the TM SGNL accident clearly illustrates this centralized method carries risks.
In the future, I expect that some branches of government – particularly those involved in national security and foreign service – will explore more decentralized communication solutions, especially for high-risk situations or sensitive communications.
Even institutions that are traditionally risk-averse will reconsider their strategy if the cost of a security breach continues to escalate.
The content of this post, Interview: Session founder Kee Jeffreys predicts that certain government departments will begin exploring decentralised messages in the near future may change as new developments unfold.
This site is for entertainment only. Click here to read more
