1

While running the simpleWebRTC example Step8 of the WebRTC codelab tutorial on my local computer 192.168.2.101 (in my own home private network), when someone (that I don't know) joined in (video + audio) (???)

I am wondering how could this have happened since I am running the WebRTC in my private network.

Could that person have sniffed packets on the simpleWebRTC STUN server while the browser was negotiating the session? I am trying to understand how he exactly did this.

enter image description here

zabumba
  • 161
  • 1
  • 8
  • Do you have any reason to assume that it was intentional? – Philipp Mar 26 '15 at 13:16
  • I am not sure it is intentional, but I can't see how it could be otherwise. Now I have 2 people connecting to my sesssion (room). I have tried changing the room name too. But here they are every time I start a session. – zabumba Mar 26 '15 at 14:04

1 Answers1

2

The WebRTC APIs provide the means to capture audio/video and transfer data to other peers. To get connected to another peer, both peers need to exchange their local session description (SDP) which contains (among other (authentication) data) the IP addresses and (random) port from where the peer can be reached. These IP addresses are found by querying the local network interfaces and via STUN. The WebRTC (RTCPeerConnection) API provides a way to generate this SDP, but not a way to transmit it to the other peer (known as signaling).

It should be clear that it is extremely unlikely to get connected to a random stranger by accident, because the browser needs to generate the SDP and also has to listen on the local port as stated in the SDP. So, most likely one of your libraries has a built-in signaling mechanism (commonly via WebSockets) to share the SDP with another peer. This turns out to be the case in your specific example: https://bitbucket.org/webrtc/codelab/src/c75c8e837a125441d2ee008c55348ac5a24a85d4/complete/step8/index.html links to http://simplewebrtc.com/latest.js, which defines a default (external) server for signaling (https://signaling.simplewebrtc.com:443/).

If you open the browser's devtools before (re)loading the page, then you can inspect the protocol messages in the Network tab.

Rob W
  • 2,113
  • 18
  • 20
  • exactly, so I'd be assuming right that my SDP was hacked (?), that's the only way they could have get hold of my NAT IP address. Yet once he has my router IP address and port, it still needs to join the same room. – zabumba Mar 26 '15 at 14:09
  • 2
    @joelmaranhao You are not being hacked. You are deliberately (unknowingly?) sending your SDP to `signaling.simplewebrtc.com`, which in turn sends the SDP to other peers. Since these peers now have your SDP, they know how to set up a connection with your browser and exchange data. – Rob W Mar 26 '15 at 14:12
  • I think I may have used the word "hacked" wrongly here. I am not being paranoid that someone is purposely hacking into my system maliciously, I am trying to understand by which mechanism they always seem to end up in my session even if I change the room name. I do understand that they got my SDP from `signaling.simplewebrtc.com` and they may have joined the same room, because I had kept the name in the code sample. Now it's still happening after I change the room name. This I still don't get it entirely – zabumba Mar 26 '15 at 14:30
  • unless the room name is part of the SDP (?) ... this is a bit new to me. Nevermind – zabumba Mar 26 '15 at 14:36
  • 1
    @joelmaranhao The room name is not a part of the SDP. For a dissection of a typical SDP as used in WebRTC, see e.g. https://webrtchacks.com/sdp-anatomy/. The room name is something application-specific, you have to find and read the source code of the server if you want to get the exact answer. Bottom line is that whenever you send something to a server, it is out of your control, and the server is free to do whatever it want with it, including passing the data (SDP) to other subscribers of the websocket channel. – Rob W Mar 26 '15 at 14:39