The single most important decision for Critical Data Protection
Information is power. The things we say and send to each other can hold immense value to us as a business, as an organization or as a private citizen. Conversely, the information we share can create significant risk when we are discussing negotiation tactics, confidential client data, a new business strategy or trade secrets. This is an especially complex issue in large organizations – both public and private. Mission critical data and highly sensitive discussions require secure communication tools that provide stronger encryption than products used for everyday communications.
Describing a communication tool as “secure” generally implies that – amongst other things – it protects all communication through encryption and authentication. While encryption is crucial, how it is used makes all the difference in the world.
The single most important security differentiator between communication platforms is whether they offer end-to-end encryption (E2E) rather than client-to-server encryption (C2S). Modern products, including Wickr networks, built exclusively with end-to-end encryption provide a new level of data and communication security. However, many other tools described as “secure” use antiquated client-to-server encryption. The use of client-to-server architecture is especially prevalent in products that offer video communication. Prominent examples would include Zoom, Slack, WebEx, Skype for Business, Telegram (in its default setting) and many others.
The distinction between end-to-end encryption vs client-to-server encryption is so important that it’s fair to say the two types of platforms are fundamentally different.
Many Small Baskets or One Huge One?
So, what’s the difference? Invariably, in any such platform all traffic is routed through a single central server. The difference between E2E and C2S platforms is that an E2E server is of little to no value to an attacker trying to steal secrets on an E2E platform. Whereas, for C2S platforms the central server contains a vast trove of highly sensitive data making it one of the single most valuable targets in your entire organization’s infrastructure.
Gaining access to a C2S messaging server means gaining access to all communication on your entire network in one fell swoop! Nor is this just about ongoing communication. When you log in to your account on a new device do you see your conversation history? If so, then so can anyone with access to that server. A compromised server can listen in and record any and all calls, see (and manipulate) all files being transferred, and read all messages being exchanged and stored as conversation histories. Compromising a single server in a C2S platform simultaneously gives the attacker access to, say, all private communication with your clients and contractors, trade secrets and operational data exchanged by your employees, legal strategies discussed with lawyers, business strategies discussed amongst the executives, negotiation tactics discussed amongst sales and so much more.
The risk of exposure of a C2S server comes not just from external attackers but often from simple negligence or accident. A recent survey found nearly 200 organizations vulnerable due to their miss-configured Amazon S3 buckets alone. For example, 300 million Wechat and QQ private messages were recently leaked due to a misconfigured database.
But regardless of how carefully we defend against those threats, a C2S server inevitably remains vulnerable to various insider attacks (e.g. Snowden, Manning, Winner, Shulte). In fact, insider attacks are, by far, the most dominant type of threat to the cybersecurity of organizations across the board making such attacks a particularly important threat to defend against. Yet, any administrator with (digital or physical) access to a C2S server also has unfettered access to all comms data on the platform. Worse, many C2S platforms actually come equipped with features which (essentially, by design) trivialize precisely such low-effort/low-skill/high-impact insider attacks. Slack, for example, offers the “Export Data” feature which lets a (rogue) administrator download the entire communication history of a Workspace in a single operation. Just as for server administrators, access to such features again means having access to a single point of failure for the security of all communication on the platform.
In contrast, on an E2E platform, all comms data is only available at the end points involved in the individual conversations. (Technically, traffic is encrypted by its sender in a way that only the intended receivers can decrypt it. The middleman, or the central server, has no ability to decrypt the message or data). So, in an E2E platform, the server does little more than blindly route encrypted traffic between clients. Thus, compromising the server leaks nothing at all about what is being said, sent or talked about in the network; neither past nor present.
But it uses “TLS”. Isn’t that good enough?
To be secure, both web traffic and messaging platforms must use cryptographic channels to secure communication between their applications’ end points. In a web browser, TLS is the industry standard protocol for building those channels.
A critical difference between browser and messaging security is where those end-points lie. For the web, servers (along with clients) are end-points. Servers host, maintain, process and filter web applications’ data. In contrast, in messaging applications the sever is no more than a middleman transparently forwarding data between end-points. In other words, while web applications naturally reflect a C2S channel structure, messaging is instead fundamentally an E2E application.
Despite its success in the web space, relying only on TLS between clients and the server is just not the right tool for securing a messaging platform. Simply put, the approach does nothing at all to avoid the huge risk of letting a single server have access to your entire organization’s communication.
Why the Large Baskets?
This heavily concentrated risk inherent to C2S-based communication and collaboration platforms should make us question our use of such tools. Must we really expose ourselves and our organizations in this way?
As demonstrated by Wickr and other E2E solutions out there, the answer is generally a pretty emphatic “No.” My communication network does not need to be able to listen to all my calls or read all my messages. We don’t need to take on this risk and it’s too much to ask corporate IT to manage it. Rather, by using the right E2E secure tools, we can operate under a much tighter regime where data and communications are accessible only by intended recipients and no one else – including service providers.
If security is significant priority for your organization, C2S communication and collaboration platforms are a bad choice.
