Is a WebRTC Data Channel Encrypted? Yes — Here Is How
DTLS, SCTP and certificate fingerprints: the encryption WebRTC mandates, what it protects against, and the one attack it cannot stop on its own.
Short answer: yes, always. Unlike the web itself — where unencrypted HTTP technically still exists — the WebRTC standard makes encryption mandatory. There is no plaintext mode to misconfigure. But “encrypted” is only half of the security story, and the other half is worth understanding.
The stack, briefly
A WebRTC data channel is SCTP (a transport protocol providing the reliable, ordered delivery) running inside DTLS (TLS adapted for datagram transports). When two browsers connect, they perform a DTLS handshake directly with each other and derive session keys that exist only in those two browsers. This design is specified in RFC 8827 (WebRTC security architecture) and RFC 8831 (data channels). The consequences:
- Every byte on the wire is encrypted with modern ciphers — there is no opt-out.
- The signaling server never holds the session keys; it relays connection metadata before the encrypted channel exists.
- A TURN relay forwards DTLS ciphertext; it also has no keys (what a relay can see).
Self-signed certificates — and why that is fine (mostly)
Browsers generate a fresh, self-signed certificate per WebRTC session — there is no certificate authority involved. Authentication instead works by exchanging certificatefingerprints through signaling: each side's SDP includes an a=fingerprint: line (you can see it in chrome://webrtc-internals), and the DTLS handshake fails unless the certificate presented matches the fingerprint that was signaled.
This chains the security of the connection to the security of signaling. If the signaling path is honest, the encryption is end-to-end with exactly the intended peer.
The one attack encryption cannot stop alone
If an attacker fully controls the signaling path, they can attempt to substitute fingerprints: terminate encryption on their own machine and re-encrypt toward each victim. Each victim then has a perfectly encrypted channel — with the attacker. This is why serious WebRTC applications add an out-of-band verification step. In ShareDrop.org both devices derive a six-digit safety code from the fingerprints they actually negotiated; a substitution makes the codes differ (full explanation). Our protocol test suite includes exactly this substitution scenario to prove the detection works.
What encryption does not cover
- Endpoints. The receiving device holds a plaintext copy after the transfer. Compromised devices defeat any transport encryption.
- Traffic analysis. Networks in the path observe that a connection existed, its volume and timing — content no, metadata yes.
- Integrity of the file as a whole. DTLS protects packets in flight; verifying the assembled file arrived complete is a separate, application-level job (how we do it).
Bottom line: the encryption question for WebRTC is settled by the standard itself. The questions worth asking a transfer tool are what it does about signaling trust (safety codes), integrity (checksums), and endpoint honesty (telling you the actual connection mode).
Verify it yourself
Nothing in this article needs to be taken on faith — the claims were checked against Chrome's actual negotiation output, and you can repeat that in two minutes. Open chrome://webrtc-internals during any WebRTC session and look at three things: the SDP offer contains an a=fingerprint:sha-256 line (the certificate hash that pins the DTLS handshake), the transport shows dtlsState: connected before any application data flows, and the data channel rides on that DTLS transport. There is no configuration in which a data channel is established without the handshake — browsers do not ship an unencrypted mode.
Standards referenced
- RFC 8827 — WebRTC Security Architecture: mandates DTLS and defines certificate fingerprints and identity binding.
- RFC 8826 — Security Considerations for WebRTC: the threat model behind these design choices.
- RFC 8831 — WebRTC Data Channels: SCTP over DTLS, the stack file bytes actually travel on.
- RFC 8445 — ICE: why encryption is identical on direct and relayed paths.