WebRTC uses DTLS for encryption of SCTP (data). Furthermore it uses DTLS for key exchange of SRTP (media). But I do not quite understand, whether it also uses DTLS for encryption of SRTP. So my question: Does WebRTC use DTLS solely for key exchange (DTLS-SRTP) or does it encrypt SRTP additionally to its internal encryption mechanism (at least optionally)?
Why I am asking:
RFC 6904 as well as RFC 3711 state that SRTP provides authentication, but not encryption, of the headers of RTP packets. So only the payload of SRTP is encrypted by design.
What confuses me:
Many sources claim WebRTC to be fully end-to-end encrypted.
I am especially interested in the implementation of WebRTC in gstreamer.
DTLS is used for the handshake, but then the keys are extracted and a SRTP context is initialized.
I am not familiar with GStreamer, but in Pion WebRTC we connect via DTLS here. The WebRTC clients negotiate which side is a DTLS Server and which is a DTLS Client via the SDP.
When the DTLS handshake is complete you then export the keying material, you can see that here
If you are interested in seeing how SRTP works you can check out pion/srtp. It is pretty simple though, it is just AES and then you generate an authentication tag. You can see it all here
Related
For webrtc peers, what domain is dtls used for negotiation? I am puzzled. There seems to be no relevant attribute definition in the sdp. Is it the domain where the web page is located?
WebRTC doesn't use a certificate authority. No domains are involved. With WebRTC the Authenticity that you get from PKI is just replaced with certificate fingerprints.
Each side generates a certificate and then shares the fingerprint in the Session Description (Offer/Answer). After the DTLS handshake is complete it makes sure that the certificate exchanged was the same.
How DTLS actually works is explained in WebRTC for the Curious#Securing a bit more.
If the signalling part of webrtc is handled by sip, is it mendatory that sip signalling has to be encrypted by TLS. Is it mendatory that sip over websocket has be encrypted as TLS
WebRTC uses TLS sessions or QUIC for its signaling transport – both are encrypted in nature. All other avenues for non-encrypted signaling don’t really exist in WebRTC. Theoretically they might work, but some browsers will either block them altogether or require the user to grant access to the camera and microphone on each interaction. Deploying anything serious to production with WebRTC without encrypting signaling for their browser implementations is not a real alternative.
WebRTC “forces” you to encrypt your signaling. What is left out of scope of WebRTC are things like authentication, authorization and identity management. You are free to do as you please in that domain – just make sure to do something here – and not leave this wide open for pranksters or worse.
For native applications on mobile, desktop or embedded – you can do whatever you like. That said, the mindset must be the same – mandatory encrypted signaling.
reference : Best webrtc related blog
I am interested in experimenting with WebRTC data streams as a method of low-latency communication between peers in multiplayer games in the browser, but have read that WebRTC is always encrypted. From http://webrtc-security.github.io/
Encryption is a mandatory feature of WebRTC, and is enforced on all components, including signaling mechanisms. Resultantly, all media streams sent over WebRTC are securely encrypted, enacted through standardised and well-known encryption protocols. The encryption protocol used depends on the channel type; data streams are encrypted using Datagram Transport Layer Security (DTLS) and media streams are encrypted using Secure Real-time Transport Protocol (SRTP).
It seems odd to me to have encryption so tightly coupled in this way. I can think of contexts where mandatory encryption is a hindrance, like multiplayer gaming where data transferred is non-sensitive and having to encrypt/decrypt data is unnecessary overhead, however small. For comparison, WebSockets communication is encrypted further down the stack by TLS if present, but the option of communicating over plain TCP is available as well. Am I misunderstanding this or is there a reason why it was decided that all WebRTC communication must be encrypted?
WebRTC is defining new realm for browsers which was not primarily intended. IMO Accessing camera/microphone rises enough resistance to use the technology solely so mandatory encryption gonna ease it.
The same reason as HTTPS communication is encrypted, they're trying to avoid a middle man to get advantage of the peer to peer communication
By WebRTC standard all connections should be encrypted via DTLS. This is great. However, unless application verifies authenticity of the peer, the connection is vulnerable to man in the middle (MITM) attack.
The question is how to do this with libWebRTC (http://www.webrtc.org/native-code) specifically in Objective C interface. Ideally, I would like to be able to specify my own certificate for WebRTC connection. In this case I will be able to verify it through my application-specific secure channel. If this is not possible, then what is the suggested approach? I will be grateful for any hints.
The WebRTC specification does not include the signaling layer, i.e., how the fingerprints, ICE candidates, etc are exchanged between peers. This means that in almost all WebRTC applications, there's a signaling socket to rapidly signal the connection with a service which exchanges the information between two peers.
Instead of supplying your own certificates or fingerprints, what you want to do is authenticate the signaling over which those are sent.
Your signaling server effectively is the man-in-the-middle, especially in cases of using an MCU or SFU. It should verify the identity of clients exchanging signaling information, and ensure the signaling information is exchanged between mutually agreeing peers (i.e., calling one another by address, or joining a common "room").
So the answer is: use secure websockets, and authenticate clients sending/receiving WebRTC offer/answer information. If you do that, there's no risk of man-in-the-middle attacks, beyond the risk of any other HTTPS+WSS application.
now I need to make webrtc SDP -> normal SDP.
so I need to encode and decode fingerprint in webrtc. I think that fingerprint is SRTP encrypt method.
anyone have experience decode and encode fingerprint. I need following step
WEBRTC SDP -> signal server(decode fingerprint, make normal rtp SDP) -> sip client.
sip client SDP(normal rtp) -> signal server(encode fingerprint, make webrtc sdp) -> WEBRTC.
and we decode and encode SRTP in turn server...
please help me
The certificate that is used to encode/decode the SRTP stream is negotiated through DTLS. You need to get the master key from the DTLS negotiation. You cannot do that through packet sniffing. You will have to use the native API and use your own certificate to decode the stream.
You will have to do something similar to the WebRTC Breaker to get the raw rtp stream. That breaker does everything you need it to and it is GPL.