CODEWITHSUNDEEP
webrtcp2psdpmediastreamvideo-conferencing
iammilind
iammilind

Reputation: 70078

Does WebRTC encrypts data from the offer SDP for the offerer and answer SDP for the answerer?

During a WebRTC call, an offerer and an answerer share offer & answer SDPs to each other respectively.
I suppose that the peers will be using some information (like fingerprint etc.) from their respective SDPs to encrypt the data, so that the other peer can decrypt and consume the media stream.

Is it like: offerer has those encrypt-decrypt info in the "offer SDP" and answerer shares in the "answer SDP"?

The purpose for this is to try out a possible implementation for an Selective Forwarding Unit (SFU), where a user uploads a stream only once. Now their offer SDP is stored somewhere in the server along with few initial signalling bytes. Whichever peer wants consume that stream, would be shared the same offer and it should work, because the encrypt-decrypt key would be part of the offer SDP.

This question is related to an effort to find out a possible solution for:
Is there any alternative approach to implement WebRTC SFU, to have only 1 upload stream?

Upvotes: 0

Views: 775

Answers (3)

舞雩夕
舞雩夕

Reputation: 1

My understanding is, accepting a SDP with fingerprint means that you believe the owner of fingerprint is reliable. Normally, we need to find a CA(Certificate Authority) to verify the fingerprint belongs to reliable organization. However, since this is a personal session, there is no CA to use.

Upvotes: 0

jch
jch

Reputation: 5651

All WebRTC traffic (media tracks, data channels) is authentified and encrypted using keys that were negotiated during the SDP exchange (offer/answer). The exchagne is invulnerable to eavesdropping: if an attacker is able to receive a copy of the offer/answer exchange, they won't be able to intercept the WebRTC traffic. On the other hand, the exchange is vulnerable to man-in-the-middle attacks: if an attacker is able to modify the offer/answer exchange, they might be able to eavesdrop and spoof the media traffic.

Therefore, the offer/answer exchange does not need to be encrypted, but it does need to be authentified. The most common way to perform the exchange is to use a channel protected by TLS (for example https or a WebSocket over TLS), but this does not necessarily authentify a client. If more security is desired, other solutions are possible; for example, it is easy enough to use the crypto.subtle API to authentify the SDP using a shared key.

Upvotes: 0

Philipp Hancke
Philipp Hancke

Reputation: 17340

Encryption in WebRTC is done using DTLS (or DTLS-SRTP). This means the encryption keys (for both directions) are negotiated between the peers with the first few UDP packets of the connection.

This encryption is using a self-signed certificate whose fingerprint you can find in the a=fingerprint: line of the SDP and is validated against this.

When forwarding media packets to another client, the SFU therefore needs to decrypt and reencrypt.

Upvotes: 4

Related Questions