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.
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
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
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
I chose SSL for registration in my game client. The client communicates with the game server which stores a salted/hashed password.
If I use SSL to authenticate users on login, but the game does all of it's communication with UDP packets, how does the server know that the UDP packets it's receiving is from the authenticated user?
Potentially you can provide a token via SSL, and pass that token in your UDP packets. But this is useless without encryption: an attacker can intercept the UDP packet, grab the token and quickly do the attack using stolen token.
Another option would be to exchange symmetric keys via SSL and use those keys to encrypt UDP packets. But to do this properly you would have to also add MAC, an finally you will end up reinventing TLS :).
The best option is to employ DTLS - the flavor of TLS that works over UDP. All your communication will be authenticated and protected this way. Possibility to use DTLS depends on what language/platform you use and what external libraries (if any) you can invoke.