Is a WebRTC Data Channel Encrypted? Yes — Here Is How
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). The ShareDrop.org 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 ShareDrop.org does 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).
What the handshake actually negotiates
The DTLS handshake between the two browsers does three things. It authenticates each side's certificate against the fingerprint announced during setup, so a certificate that was not the one promised is rejected. It agrees a cipher: in current browsers an elliptic-curve Diffie–Hellman exchange for the keys and AES in GCM mode for the data. And it derives session keys that exist only in the two browsers' memory. Because the key exchange is ephemeral, the keys cannot be reconstructed later even by someone who obtains a certificate's private key afterwards — forward secrecy, the same property modern HTTPS has. The certificates themselves are self-signed and generated fresh per session; no certificate authority is involved, because trust comes from the fingerprint in the signaling exchange, not from a chain of authorities.
Encrypted against whom
| Party | Can read the file? | What they can do or see |
|---|---|---|
| Someone on the same Wi-Fi | No | Sees encrypted packets: sizes, timing, the two endpoints |
| Your ISP or the venue's network | No | Same, plus which relay or STUN server was contacted |
| The relay operator | No | Both endpoints' addresses, sizes and timing; forwards ciphertext it cannot open |
| The signaling operator | No | Could attempt a substitution during setup — which the safety code detects |
| An active attacker who controls the introduction | Only by completing a man-in-the-middle | Produces mismatched safety codes on the two screens |
| The browser vendor | No | Keys are in the page's process memory; no vendor service participates |
| The recipient | Yes | That is the point |
The padlock and the data channel are two different things
The padlock in the address bar is TLS between your browser and the web server that served the page. The data channel is DTLS between your browser and the other person's browser. They use related cryptography and protect different links. The padlock matters for a reason that is easy to miss: it guarantees the JavaScript that runs the transfer was not altered on the way to you. A page delivered over plain HTTP could be rewritten by a network attacker to skip the fingerprint check, and no amount of encryption afterwards would help. That is why the transfer page is only ever served over HTTPS.
Media channels versus data channels
WebRTC carries audio and video with SRTP and everything else with SCTP over DTLS. A file transfer uses only the second. The distinction matters when reading security analyses: several well-known WebRTC weaknesses concern media (codec fingerprinting, traffic-analysis of voice) and do not apply to a data channel carrying fixed-size chunks of a file.
What encryption does not hide, in practice
An observer sees a stream of packets of nearly constant size (a 64 KiB chunk becomes a predictable burst of datagrams) for a predictable duration. From that they can estimate the total size of what was sent to within a few percent, and they know exactly when it happened and between which two addresses. No padding is applied, because doubling the traffic to hide a file size is a poor trade for a transfer tool. If the fact that a transfer of about 2 GB happened at 14:32 is itself sensitive, the mitigation is a VPN or a relay for the address part; nothing practical hides the size (the full picture of what leaks).
Three myths, briefly
- “WebRTC leaks your IP, so it is insecure.” A direct connection reveals your address to the peer, by definition. That is a privacy consideration about who you connect to; it has nothing to do with whether the contents are readable, which they are not.
- “The relay can decrypt because it is in the middle.” Being in the path is not the same as holding the keys. The relay forwards the encrypted handshake like any other packet and never learns the result.
- “Open Wi-Fi breaks the encryption.” Wi-Fi encryption protects the radio link; the data channel is encrypted above it, end to end. An open network exposes metadata, not contents (what public Wi-Fi really risks).
Why WebRTC made encryption mandatory
Earlier real-time protocols (SIP and RTP, the basis of most voice-over-IP) made encryption optional, and in practice a large share of calls went unencrypted for a decade because the option was never switched on. When WebRTC was designed in the early 2010s, the working groups decided not to repeat that: there would be no unencrypted mode at all. Media must use SRTP with keys from DTLS; data channels must run over DTLS; a browser that offered a plaintext option would be non-compliant. The decision was argued at the time as a burden on implementers; it is the reason a question that used to be “did the developer turn it on?” is now answered by the standard itself. It is also why this article can be short about the mechanics: there is only one way for a WebRTC transfer to work, and it is encrypted.
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.
