skip to content

Can a WebRTC application switch encryption off to save CPU or let a network probe record calls, and what does RFC 8827 require instead?

level: middleimportance: should knowfreq 27%

answer

  1. no plain RTP in WebRTC
  2. no NULL cipher suites
  3. DTLS for data too
  4. keys never reach the page script
  5. record at an endpoint

basics

~20 s

No. RFC 8827 requires all WebRTC media to be sent as SRTP keyed with DTLS-SRTP, forbids plain RTP and NULL-encryption cipher suites, secures every data channel with DTLS, and forbids the API from exposing the keys to the page's script.

solid answer

~50 s

No — encryption is not a WebRTC option. RFC 8827 says all media channels **MUST** be secured with SRTP and SRTCP, media **MUST NOT** be sent as plain RTP or RTCP, implementations **MUST NOT** negotiate NULL-encryption cipher suites, DTLS-SRTP **MUST** be offered for every media channel, and SDP security descriptions must not be offered or accepted. All data channels **MUST** be secured via DTLS. The API also **MUST NOT** let the page's JavaScript obtain the negotiated keying material, so the application cannot leak keys to a probe either. The W3C `RTCConfiguration` has no member to disable any of it. A probe on the path sees addresses, timing and sizes, never the media; recording must happen at a party to the call — one of the endpoints, or a media server that terminates the participants' connections.

go deeper

for a junior

Remember that every WebRTC call is encrypted: media as SRTP, data channels inside DTLS, with no setting to turn it off.

for a middle

Explain RFC 8827's rules: SRTP for all media, no NULL ciphers, DTLS-SRTP offered on every channel, DTLS for data, and keys withheld from the page's script.

for a senior

Show where recording and monitoring must live when no observer can decrypt, and why a media server that terminates connections is inside the protection boundary.

for a principal

Frame the trust boundary for a product line: when hop-by-hop protection is enough, when content must be hidden from your own servers, and what recording and compliance commitments each choice allows.

## The short answer: there is no off switch Teams arriving from SIP or older RTP systems sometimes expect an "unencrypted mode" for debugging, lawful recording or saving CPU on low-end devices. WebRTC has none. The security architecture, **RFC 8827**, makes encryption a mandatory property of every WebRTC media and data path, and the W3C WebRTC 1.0 API gives an application no way to opt out: `RTCConfiguration` holds `iceServers`, `iceTransportPolicy`, `bundlePolicy`, `rtcpMuxPolicy`, `certificates` and `iceCandidatePoolSize`, and nothing that weakens protection. ## What RFC 8827 requires Section 6.5, "Communications Security", lists the rules. Paraphrased with their requirement levels: | Requirement | Level | |---|---| | Support SRTP, DTLS, DTLS-SRTP keying and SCTP over DTLS | MUST | | Secure all media channels via SRTP and SRTCP | MUST | | Send media over plain, unencrypted RTP or RTCP | MUST NOT | | Negotiate cipher suites with NULL encryption modes | MUST NOT | | Offer DTLS-SRTP for every media channel | MUST | | Offer SDP security descriptions, or select them if offered | MUST NOT | | Secure all data channels via DTLS | MUST | | Support DTLS 1.2 with `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` and P-256 | MUST | | Support the `SRTP_AES128_CM_HMAC_SHA1_80` protection profile | MUST | | Favour forward-secret cipher suites over non-forward-secret ones | MUST | How the DTLS handshake produces the SRTP keys, and why keys sent inside SDP were rejected, are separate subjects; for this question it is enough that every packet of media or data is protected by keys negotiated between the two DTLS endpoints. ## API requirements that close the side doors RFC 8827 also constrains the browser API, because a web page is untrusted code: - **The API MUST NOT permit the script to obtain the negotiated keying material** when DTLS-SRTP is used. A page therefore cannot read the SRTP keys and hand them to a recorder or a network probe. - **A new authentication key pair per call by default**, so calls are not linkable through a stable certificate. - **A means to reuse a key pair** where the application wants continuity; in the W3C API that is the `certificates` configuration member, filled with `RTCPeerConnection.generateCertificate()`. - **Different key pairs per origin** unless the user configures one, so a certificate cannot become a cross-site identifier. Supplying a certificate changes the connection's identity, not the protection: the handshake still runs, and the keys still stay out of the script's reach. ## What a network observer still sees Encryption hides the content, not the call: - the endpoints' addresses and ports, and any relay in between; - packet timing, sizes and volume, which reveal when someone speaks or how much motion a video carries; - the unencrypted parts of the packets, because SRTP encrypts RTP and RTCP **payloads** while authenticating the headers. A TURN relay sits in that observer's position too: it forwards the protected packets and never holds the keys. ## Where recording and monitoring have to live Since nobody on the path can decrypt, anything that needs the media must be a **party to the call**: 1. **An endpoint records.** The application records the local and remote tracks it already has in decoded form, with the user's knowledge. 2. **A media server joins.** A server that terminates each participant's peer connection is a DTLS endpoint for each leg, so it receives decrypted media and can record, transcribe or bridge it. 3. **Quality monitoring uses statistics, not packets.** Each endpoint reports loss, jitter and round-trip time through the API's statistics, without exposing content. The second option shows the boundary of the guarantee: DTLS-SRTP protects each **hop** between DTLS endpoints, so a media server that terminates connections sees plaintext. Keeping content from such a server needs an additional end-to-end layer on top, a separate design. ## Why the IETF made it mandatory - **Untrusted networks.** Browsers run calls from cafés, hotels and mobile networks the user does not control; an optional mode would be downgraded by an attacker or left off by default. - **Untrusted pages.** A web application should not be able to disable protection silently or extract keys. - **Cost is small.** Symmetric encryption of each packet is cheap beside encoding the video in it, so "saving CPU" buys little.

  • If WebRTC media is always encrypted, why is a media server still able to record a group call?
    Because DTLS-SRTP protects each hop between two DTLS endpoints, and a media server that terminates every participant's peer connection is one of those endpoints on each leg. It decrypts what it receives and re-protects what it sends, so it holds plaintext media. Hiding content from such a server needs an extra end-to-end encryption layer above DTLS-SRTP.
  • Can a WebRTC page supply its own certificate, and does that let it weaken or read the encryption?
    It can supply one: `RTCPeerConnection.generateCertificate()` creates an `RTCCertificate`, passed in the `certificates` member of `RTCConfiguration`, which RFC 8827 allows for key continuity. It changes which identity the DTLS handshake presents, not the protection: the handshake still runs, the cipher suites stay mandatory, and the API still must not expose the negotiated keying material.

saying these in an interview costs you the question

  • WebRTC media is plain RTP unless the developer enables SRTP
  • Encryption can be disabled on a peer connection for debugging
  • Data channels are unencrypted; only audio and video use SRTP
  • A recorder can capture the keys from JavaScript and decrypt traffic later
  • A TURN relay sees the media because it terminates the encryption
  • A media server in the call cannot read the media because WebRTC is end to end