End-to-end encryption for Pusher Channels is out of beta

End-to-end encryption for Pusher Channels is now out of beta and implemented across many of our SDKs! Now you can add end-to-end encryption to your application with one line in your server configuration, whatever your stack.

What problem does end-to-end-encryption solve?

We created the E2EE encryption feature in Channels with the following motivation:

To ensure event data payloads can be unavailable to both Pusher and our infrastructure providers (e.g. AWS).

Communication between customers and Pusher, and Pusher and our customers’ end users is encrypted with TLS. This excludes all other entities external to Pusher from having access to the contents of customer events.

Consider a pharmacy app which lets patients submit prescription requests to their pharmacist. When a new request comes in, the pharmacy needs to be informed as quickly as possible, so that they can have the request approved and arrange a collection. For realtime delivery such as this, you can use Pusher Channels.

These requests include sensitive details. A patient might submit information relating to their health or personal data. In such cases, the “principle of least privilege” applies, which means you need to restrict access to only the people that require it. This list includes the patient, the pharmacist, and a physician who will approve the request.

As developers, we have several tools to enforce the principle of least privilege: your login system, TLS, and “private channels”. Your online pharmacy login system prevents attackers from impersonating a privileged user such as a doctor.

TLS (SSL) prevents attackers from reading or manipulating data sent between remote parties on the open internet. Pusher Channels’ “private channels” feature prevents attackers from posing as another user to read sensitive data.

However, this still leaves Pusher with potential access to event data. It’s better for everyone if our customers can choose to remove that potential.

Better for our customers, because it reduces the level of trust they must have in us to believe that their communications are secure.

Better for Pusher, because it removes any potential for us to break that trust.

End-to-end encryption is an important tool to help you enforce the principle of least privilege. It removes Pusher from the list of privileged entities that can read and write sensitive data such as prescription requests.

Pusher Channels holds long-lived open connections to your users’ apps so that you’re always in instant contact with your users. To do this, Pusher Channels sits as a proxy between your server and your users.

As a proxy, Pusher Channels is technically a man-in-the-middle, a privileged user. Despite TLS being used from your server to Pusher Channels, and from Pusher Channels to your users, messages are in plaintext while they flow through our internal systems.

End-to-end encryption solves this problem by ensuring that sensitive data is encrypted even while it flows through our internal systems.

How we built end-to-end encryption for Channels

In designing the encryption feature, we leant on the work of the NaCl group to provide an appropriate encryption scheme and parameters for the needs of the feature. Never roll your own crypto!

We chose the SecretBox primitive, which allows the symmetric encryption of data.

We leverage the existing communications channel between end-users and customers which is established by the Pusher libraries – the authentication flow of private channels – to distribute decryption keys to end-users. This is a direct communication between the end user and customer backend, which does not flow through Pusher’s infrastructure.

The backend libraries, which the customer integrates into their backend service and which run on their infrastructure, derive and distribute a key per channel to end-users who successfully authenticate against encrypted channels.

The websocket libraries, which the customer integrates into their application and which run on end user devices, receive decryption keys as part of the authentication responses they make for encrypted channels.

At no point is the key passed via Pusher infrastructure.

The key is handled on both ends by Pusher’s libraries, in order to provide this functionality with minimal effort on the part of the customer. All of these libraries are open source, so it can be verified that the keys are never forwarded to Pusher.

To get started with end-to-end encryption in Channels, check out our docs.