Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Study of WebRTC Security

webrtc-security.github.io

Post reply on HN
Print view View original

31–38 of 38 posts

Re: A Study of WebRTC Security

#31

Post by jsprogrammer »

moron4hire wrote: post #29
jsprogrammer wrote: post #23

Earlier quoted context omitted.

https://github.com/blakelapierre/instantfile https://github.com/blakelapierre/instantchat Can't say whether the HEADs work or not. They currently aren't hosted live at the moment, either.

So other than hosting your own TURN server, you're not doing anything that my own home grown code was doing, leading me to believe that this will not work very reliably. My problem wasn't making confections, it was making them reliably.

You must follow the 52ish-step handshake protocol pretty much exactly to have any hope of reliably creating connections across OS/browser platforms.

I don't think I had seen any handshake failures in the final versions of the code in those projects.

Also, you need a TURN to work reliably over every possible NAT topology (though, a few years ago I think only about 5% of connections in the wild required TURN).

Re: A Study of WebRTC Security

#32

Post by Senji »

moron4hire wrote: post #21
Senji wrote: post #17

Earlier quoted context omitted.

Send a sinewave outside the human hearing range and check for it on both ends.

That's an interesting idea. I wonder if the audio compression codec wouldn't obliterate it, though. Typically, they are supposed to be designed for human speech-level audio. Regardless, there is nothing within the WebRTC spec for dealing with failed connections. I suppose you could close the WebRTCPeerConnection object, drop it on the floor for the GC to find, and make a new one. But the entire point of providing a l…

You should be ok as long as you keep it bellow the nyquist freq.

Re: A Study of WebRTC Security

#33

Post by moron4hire »

jsprogrammer wrote: post #31
moron4hire wrote: post #29

Earlier quoted context omitted.

So other than hosting your own TURN server, you're not doing anything that my own home grown code was doing, leading me to believe that this will not work very reliably. My problem wasn't making confections, it was making them reliably.

You must follow the 52ish-step handshake protocol pretty much exactly to have any hope of reliably creating connections across OS/browser platforms. I don't think I had seen any handshake failures in the final versions of the code in those projects. Also, you need a TURN to work reliably over every possible NAT topology (though, a few years ago I think only about 5% of connections in the wild required TURN).

I had a TURN server, I just meant I didn't host it myself. But the metering showed it was never active! I kept getting a connection that succeeded through STUN, but no audio would actually come through in about 50% of WAN cases. It would always work on the LAN. Is it possible to just have a janky STUN server that negotiated a bad connection for you? Seems like a really weird failure mode. I was using Xirsys at the time as they have a mostly bare-bones setup.

Re: A Study of WebRTC Security

#34

Post by jsprogrammer »

moron4hire wrote: post #33
jsprogrammer wrote: post #31

Earlier quoted context omitted.

You must follow the 52ish-step handshake protocol pretty much exactly to have any hope of reliably creating connections across OS/browser platforms. I don't think I had seen any handshake failures in the final versions of the code in those projects. Also, you need a TURN to work reliably over every possible NAT topology (though, a few years ago I think only about 5% of connections in the wild required TURN).

I had a TURN server, I just meant I didn't host it myself. But the metering showed it was never active! I kept getting a connection that succeeded through STUN, but no audio would actually come through in about 50% of WAN cases. It would always work on the LAN. Is it possible to just have a janky STUN server that negotiated a bad connection for you? Seems like a really weird failure mode. I was using Xirsys at the ti…

If you were going across browser versions/platforms, it's possible that an appropriate audio codec couldn't be negotiated...perhaps some browsers use different codecs for different network conditions? It seems unlikely, but possible.

So, you had video, but no audio?

Re: A Study of WebRTC Security

#35

Post by samsonradu »

TD-Linux wrote: post #20
samsonradu wrote: post #16

In my opinion their secure communication acts as a double-edge sword for WebRTC. Now one-to-many streaming is complicated since you cannot easily add a man-in-the-middle streaming server like you'd do in a normal setup. Trying to broadcast to >5 users on a Chrome tab really heats up my laptop.

In fact, you can easily add a streaming server in the middle (and many-participant WebRTC servers do exactly this), it's just that you can't have it happen unintentionally.

Could you please elaborate? I've looked over the Kurento[1] Media Server page but I didn't find it that 'easy'. Would you use a tool alike or implement the negotiation yourself?

[1] http://doc-kurento.readthedocs.io/en/stable/introducing_kure...

Re: A Study of WebRTC Security

#36

Post by moron4hire »

jsprogrammer wrote: post #34
moron4hire wrote: post #33

Earlier quoted context omitted.

I had a TURN server, I just meant I didn't host it myself. But the metering showed it was never active! I kept getting a connection that succeeded through STUN, but no audio would actually come through in about 50% of WAN cases. It would always work on the LAN. Is it possible to just have a janky STUN server that negotiated a bad connection for you? Seems like a really weird failure mode. I was using Xirsys at the ti…

If you were going across browser versions/platforms, it's possible that an appropriate audio codec couldn't be negotiated...perhaps some browsers use different codecs for different network conditions? It seems unlikely, but possible. So, you had video, but no audio?

No, I wasn't using video. This is for a WebVR app, so the people are rendered as avatars.

Re: A Study of WebRTC Security

#37

Post by TD-Linux »

samsonradu wrote: post #35
TD-Linux wrote: post #20

Earlier quoted context omitted.

In fact, you can easily add a streaming server in the middle (and many-participant WebRTC servers do exactly this), it's just that you can't have it happen unintentionally.

Could you please elaborate? I've looked over the Kurento[1] Media Server page but I didn't find it that 'easy'. Would you use a tool alike or implement the negotiation yourself? [1] http://doc-kurento.readthedocs.io/en/stable/introducing_kure...

Perhaps an easier example is Janus, such as their 2-way demo that forwards all media packets through the Janus server: https://janus.conf.meetecho.com/videocalltest.html

Or the more complex demo, for a video conference where all media is forwarded through the Janus server: https://janus.conf.meetecho.com/videoroomtest.html

Re: A Study of WebRTC Security

#38

Post by jsprogrammer »

moron4hire wrote: post #36
jsprogrammer wrote: post #34

Earlier quoted context omitted.

If you were going across browser versions/platforms, it's possible that an appropriate audio codec couldn't be negotiated...perhaps some browsers use different codecs for different network conditions? It seems unlikely, but possible. So, you had video, but no audio?

No, I wasn't using video. This is for a WebVR app, so the people are rendered as avatars.

So, you were still getting a data connection, just no audio?
Post reply on HN