Trust · 9 min read
Is your video call really end-to-end encrypted?
Every WebRTC call is encrypted. That is not the same as end-to-end encrypted. The difference is who holds the keys — and here is how to work out which one you have.
Every WebRTC call is encrypted. Every single one — the standard forbids sending media any other way. So when an app tells you your calls are “encrypted”, it is telling you something that is true of literally all of its competitors, and nothing about whether anyone can watch.
The question worth asking is narrower: who can decrypt it?
Encrypted in transit vs end-to-end
Encrypted in transit means the data is protected on each hop of its journey. Your video is encrypted to the server, decrypted there, then re-encrypted to the other person. At the moment it sits inside the server, it is plaintext. Anyone with access to that machine — an administrator, an intruder, a court order — can see it.
End-to-end encrypted means only the two devices hold the keys. Whatever sits in between carries data it cannot read. The strength of the promise comes from the keys never leaving the endpoints, not from the strength of the cipher.
Both are honestly described as “encrypted”. Only one keeps the operator out.
One-to-one direct calls are end-to-end by construction
When two browsers connect directly, the DTLS handshake happens between those two devices. The keys are derived on your machine and theirs and never exist anywhere else. There is no third party in the media path to decrypt anything, because there is no third party at all.
You don't have to trust a policy for this. It follows from the shape of the connection.
A TURN relay does not break end-to-end encryption
This one is widely misunderstood, so it's worth stating clearly.
When a direct route can't be found, WebRTC falls back to a TURN relay, which forwards packets between the two peers. Media does then flow through a server. But the DTLS handshake is still between the two browsers — TURN operates below it, forwarding sealed packets it has no key for.
A TURN operator learns that you and another address are exchanging traffic, roughly how much, and for how long. It does not learn what is in it. Metadata, not content.
So “media touched a server” and “the operator can watch” are not the same claim. It depends entirely on whether that server terminates the encryption.
Group calls are where it usually stops being end-to-end
A group call almost always runs through an SFU. To route each participant's streams sensibly, a conventional SFU terminates DTLS with every participant separately — it decrypts what arrives and re-encrypts what it forwards. At that point the server holds keys, and the call is encrypted in transit rather than end-to-end.
This is fixable, and some products have fixed it, by adding a second layer of encryption inside the first — SFrame, implemented through insertable streams — so the SFU can route frames it cannot read. It is genuine end-to-end encryption over a server. It is also extra work, which is why it tends to be a headline feature where it exists, and absent where it isn't mentioned.
A reasonable rule: if a service offers cloud recording or server-side transcription of a call and has not said the words “end-to-end” with a technical explanation attached, its server can see that call.
The real weak point is signalling, not the cipher
Nobody is going to break the encryption. They are going to go around it.
Recall from how WebRTC works that each side advertises a fingerprint of its certificate through the signalling channel, and verifies after the handshake that the certificate it received matches. This binds “the connection is encrypted” to “encrypted with the person I meant”.
Now suppose the signalling server is hostile. It can sit in the middle, terminate a connection with each of you, and pass its own fingerprints along in place of yours. Both of you see a perfectly valid encrypted call. Both of you are encrypted to the attacker.
This is the classic machine-in-the-middle attack, and it is available to whoever runs signalling in any system — peer-to-peer included. Strong ciphers do not help. The only defence is checking that the keys are the ones you expected.
How systems close that gap
- Out-of-band verification. Secure messengers show a safety number or emoji string that both people compare over another channel. If they match, no one is in the middle.
- Pinning on first use. Remember the fingerprint you saw the first time, and refuse to connect if it changes later. This doesn't protect the very first call, but it means an attacker has to be present from the beginning and never absent — a much higher bar.
ClearChat does the second. When you save a contact, its DTLS fingerprint is stored in your browser alongside the link. Reconnecting to that saved contact checks the fingerprint, and the connection is refused outright if it doesn't match. It's trust-on-first-use, with the honest caveat that comes with it: it hardens every call after the first, not the first one.
Questions worth asking any video app
- Does media pass through your servers, or only signalling?
- If it does, do those servers hold decryption keys?
- Are group calls end-to-end encrypted, or only one-to-one calls?
- Can I verify the other person's key, and what happens if it changes?
- What metadata do you keep — who called whom, when, for how long?
Question five catches out more services than the first four combined. Content and metadata are different things, and a service can be entirely honest about protecting one while retaining the other.