Is peer-to-peer file sharing secure? DTLS and WebRTC

"Encrypted file transfer" is thrown around so casually that it has lost meaning. Some tools call an HTTPS upload encrypted — which it is, in transit — but the server still sees the full file. This post separates real security from marketing by looking at the WebRTC stack ShareFile uses, layer by layer.

The short version: WebRTC encrypts every peer-to-peer data channel with DTLS, and the keys never exist anywhere but on the two devices. The security you get is real end-to-end encryption — your files are unreadable at rest and in transit, because they are never stored and never relayed without encryption.

Where encryption happens in WebRTC

DTLS on the data channel

Behind the scenes, WebRTC runs the same cryptographic machinery as HTTPS. Each peer generates keys during a TLS-style handshake that has been adapted for UDP — that is DTLS, specified in RFC 6347. Data channels negotiate a cipher suite, verify each other's certificates, and only then open the pipe. Because the connection is point-to-point, the encryption keys live in two places on earth: your browser and your recipient's browser.

SRTP for media, SCTP for files

If you use WebRTC for calls, audio and video ride SRTP (Secure Real-time Transport Protocol), a specially built encrypted media transport. File data, however, travels over SCTP running inside DTLS — the same negotiated keys, applied to a reliable message stream. Whether it is a voice frame or a 900 MB package, it is encrypted with DTLS before leaving the device.

The trust boundary nobody talks about

End-to-end encryption still needs a handshake, and someone has to carry the handshake messages between two devices that have never met. That someone is the signaling server. If an attacker controls signaling, they can present their own keys to each side — the classic man-in-the-middle — even though the transport is "encrypted".

• Signaling must run over HTTPS, so handshake messages can't be read or rewritten in transit.
• The rooms table used for signaling is treated as metadata-only and is never used to inject identities.
• Because ShareFile itself runs the signaling channel, ShareFile is the trust anchor. We document what we can and can't see in the privacy policy.

An encrypted channel is only as trustworthy as the entity that arranges it. With P2P, that entity holds no file bytes — only the session description that lets the peers meet securely.

What ShareFile can see (and can't)

It helps to be precise about what a P2P service operator actually has access to:

• It can see signaling metadata: which two peers met, when, under which room code, and basic browser/IP logging.
• It can see the file name and size you declare when registering the transfer in the room.
• It cannot see file bytes, chunks, or decrypted content — those never transit any ShareFile server.
• It cannot reconstruct a transfer after the channel closes; nothing persists.

Remaining risks, honestly stated

• Malware: encryption does not judge content. A virus sent P2P and opened locally is every bit as dangerous as one from a cloud link. Scan files you receive.
• Signaling compromise: if signaling were hijacked, a sophisticated MITM becomes theoretically possible. HTTPS and access controls mitigate this.
• Recipient transparency: end-to-end encryption is only as good as who you share keys with — i.e., who you're sending to.

Conclusion

Peer-to-peer file sharing with WebRTC is genuinely end-to-end encrypted, with no server copy to leak, retain, or subpoena. The residual risks are the ones any tool has: malicious content and who you trust on the other end. If that trade-off sounds right, try it for free — or read how it works in detail in the P2P explainer.