Reinventing Secure Messaging: A Deep Dive with Session Co‑Founder Kee Jefferys

Q1. Can you briefly walk us through Session’s origin story and what motivated you to build a decentralized messaging network?

Session is the joint creation of hundreds of contributors from all around the world—that’s the beauty of open-source software; anyone can write and contribute code to the Session codebase. Every product, however, has a more central founding story. For Session, the original founders wanted to build a proof-of-concept application atop a newly established decentralized network. We thought the best proof-of-concept application was to build a messaging application that stored and routed messages through this decentralized network, because once you had a basic messenger, you could generalize this concept to many other applications which often boil down to passing messages from one device to another. Session launched under a different name and grew immediately. It became clear that attention should be focused on Session, and what was originally designed as a proof of concept grew into one of the largest private messaging applications available today.

Q2. The recent CISA emergency directive identified two critical flaws in TM SGNL. From your perspective, what went wrong in the design or implementation that allowed attackers to harvest chat logs and metadata?

This is a classic case of cascading design and implementation issues which, by themselves, might not be exploitable but when combined can cause a catastrophic failure in the security of a network. 

The first failure was in design, TeleMessage took Signal, a well-renowned secure messaging application, and added what amounted to an intentional back door in the app for the purpose of creating an audit log. The way this audit log functioned was by sending a copy of every message a user sent, before it was end-to-end encrypted to a single central server, that server would then store a copy of all of these messages in an unencrypted state. This created the honeypot for attackers of extremely sensitive data, a treasure trove of national security information irresistible to hackers. 

The second failure was a misconfiguration of a service (Spring Boot Actuator) which ran on the TM SGNL archive server. This is a very basic misconfiguration issue where a URL typically used by developers to diagnose bugs was left open for anyone to use without authentication. This allowed attackers to dump the memory of the server, in that dump unencrypted messages and authentication information for users were visible in plaintext which allowed hackers to recover messages and account information  

It’s important to note that both failures needed to coexist for a hack of this scale to occur. This is often the case in cybersecurity breaches, that attackers will find a single design or implementation flaw and then use that flaw to find other vulnerabilities to exploit.

Q3. How common is it for E2EE clients—even Signal-compatible ones—to introduce such weaknesses, and why aren’t these caught earlier?

Common consumer-grade messaging applications like WhatsApp, Signal, and Telegram typically have much better security around their servers than the TeleMessage servers did. However, when it comes to messaging applications developed and modified explicitly to create an audit log of conversions it’s more common to see these types of misconfigurations. Especially when those applications have closed-source code, community security researchers don’t have the same ability to analyse the code for weaknesses, so common misconfigurations can go undiscovered for a long time or be kept secret by state-level hackers to maintain backdoors in the systems which are not fixed. 

Q4. You’ve argued that as long as a single vendor controls key parts of the stack, there’s an inherent risk. How does vendor centralization translate into real‑world privacy failures?

Vendor centralization is usually combined with closed-source code and centralized servers. When a messaging service stores all user messages in a single central location it creates a honeypot for attackers, they know that by breaching a single server they get access to all messages sent via the service. When combined with closed-source code which can’t be reviewed by open source security researchers and auditors, the incentive for attackers increases, and bugs which would have been discovered go unnoticed by all but the most sophisticated attackers who keep these bugs private so they can persist their backdoor access, leaving all users of the service compromised. 

Q5. Could you share an example (outside of TM SGNL) where a vendor‑side flaw undermined end‑to‑end encryption’s guarantees?

Signal’s use of Twilio for SMS verification resulted in some Signal users’ accounts being compromised when Twilio was hacked. Since SMS verification is one of the ways Signal users can recover their accounts, when Twilio was hacked, attackers could trick Signal servers into thinking that they owned the phone number of a Signal user and recover their account, using this access to send unauthorized messages from those Signal users accounts. https://support.signal.org/hc/en-us/articles/4850133017242-Twilio-Incident-What-Signal-Users-Need-to-Know 

Q6. Why do you believe decentralization is the only way to fully mitigate single‑vendor risk?

Decentralization is the only way to fully mitigate single-vendor risk because it removes the single point of failure inherent in any centralized system. When a single entity controls key parts of the stack – from user identities to message routing and storage – they become an irresistible target for attackers, and their design or implementation flaws can have catastrophic consequences, as seen with TM SGNL.

In a decentralized network, there’s no central server to be breached, no single company to be pressured into inserting backdoors, and no sole database to be targeted for metadata collection. User identities are often cryptographic keys, not real-world identifiers tied to a central authority. Messages are routed and stored across a distributed network of independent nodes, meaning no one node sees both sender and receiver IP addresses, and no single entity can collect a comprehensive log of communications. 

This distribution of power and data inherently makes the system more resilient to attacks, censorship, and data exploitation because there’s no single choke point to exploit. The security isn’t dependent on the trustworthiness of one company, but rather on the collective integrity and robust cryptographic design of the distributed network.

Q7. Session uses a network of service nodes. How does this architecture ensure that no one party can compromise user data?

Unlike traditional messaging apps, Session doesn’t rely on a single central server that stores all user data. Instead, messages are routed through a distributed network of thousands of independent community-operated Session Nodes. This eliminates the “honeypot” effect of a single centralized database, making it extremely difficult for any single entity to collect comprehensive encrypted messages and metadata.

Session nodes temporarily store messages for offline recipients. However, these messages are end-to-end encrypted, meaning the nodes themselves cannot read the content. Furthermore, messages are only stored for a limited time (Time-To-Live) and can be deleted once read, preventing long-term retention on the node network.

Additionally Session employs a modified onion routing technique, similar to Tor. When you send a message, it’s encrypted in layers, and each layer is peeled off by successive Session Nodes. Crucially, no single node knows both the sender’s and the recipient’s IP addresses. This means that even if a node were compromised, it couldn’t link a message back to its origin or destination.

Session accounts are generated cryptographically without requiring any personal information like phone numbers or email addresses. This means there’s no real-world identity linked to your Session Account ID, further enhancing privacy and making it harder to compromise a user’s identity through external data breaches.

This multi-layered approach, with no central point of control, temporary storage, end-to-end encryption and anonymized routing, ensures that even if a small number of Session Nodes were compromised, the overall integrity and privacy of the network would remain intact.

Q8. Given TM SGNL’s deployment in federal agencies, do you see governments moving toward truly decentralized messaging? What barriers exist to that shift?

That’s a tough one. Government agencies typically require audit logs to be created and stored in a way that is viewable by an auditor, this creates an inherent security vulnerability, end-to-end encryption is designed so that only conversation participants should see the contents of communications. The audit requirement introduces an intentional back door into end-to-end encryption which is hard to implement in a secure way.

However, there are ways that this can be better managed, for example the audit log should always be stored encrypted at rest and there should be robust protections around the users who can access that audit log. Governments should use open-source tools which can be easily audited and think extremely carefully about how audit logs are stored and what servers they are stored on. 

If regulation were updated, it could offer a way for decentralized solutions to be better leveraged in government communications. 

Q9. How would you persuade a security‑conscious organization to migrate from a Signal‑compatible proprietary client to Session?

I think the TM SGNL hack provides the clearest incentive yet for users to move away from proprietary technical solutions to open-source tools like Session, which offer far enhanced security and privacy features. It may be possible in the future for organizations to take open-source tools like Session and develop their own auditing tools which plug into these tools. However, such auditing solutions should themselves be open-source and auditable to ensure we don’t see the same issues as TM SGNL re-emerging.  

Q10. Looking ahead, what major features or improvements are on Session’s roadmap for the next 12‒18 months? Ultimately, what’s your long‑term vision for Session and for secure, private messaging at large?

Session’s current focus is on reaching more users. Session already has over a million monthly active users, but we want to see even more users choosing solutions which embed strong privacy and security at the core of the application design. Session contributors are currently working on a premium suite of features for power users of Session which enable sustainable funding for the Session ecosystem. This includes features like larger groups, more profile customizability, and increased file sizes, all features which increase the utility of Session. 

More broadly, I see Session as the only app which offers both content and metadata privacy in a highly consumable and easy-to-use experience, and I think as data breaches continue to impact users, Session will see continued growth over the next 12-18 months.