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

21–30 of 38 posts

Re: A Study of WebRTC Security

#21

Post by moron4hire »

Senji wrote: post #17
moron4hire wrote: post #14

It'd be one thing if WebRTC actually worked, then we could maybe talk about trade offs and whether or not the functionality is worth the negative impact. But WebRTC is a real shit-show right now. It's a 5 year old spec that doesn't have a single complete implementation, and no two implementations are even close to being reasonably compatible. I challenge any one person to write a WebRTC-utilizing app, from just the s…

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 list of STUN servers is that it's supposed to find the one that works for you.

I also just found out that, even though Tokbox (the 3rd party framework I'm using for WebRTC now that I've admitted I have more important things to do than screw around with this) is communicating a P2P video or audio connection, it cannot also let you negotiate a P2P data channel.

Re: A Study of WebRTC Security

#22

Post by moron4hire »

jsprogrammer wrote: post #18
moron4hire wrote: post #14

It'd be one thing if WebRTC actually worked, then we could maybe talk about trade offs and whether or not the functionality is worth the negative impact. But WebRTC is a real shit-show right now. It's a 5 year old spec that doesn't have a single complete implementation, and no two implementations are even close to being reasonably compatible. I challenge any one person to write a WebRTC-utilizing app, from just the s…

I've had a WebRTC app tested working under multiple OS's (Windows, Linux, Android) and browsers (Chrome, Firefox, IE, Chrome for Android). It did take more than a month to get to that point though.

Repo or it didn't happen.

Re: A Study of WebRTC Security

#23

Post by jsprogrammer »

moron4hire wrote: post #22
jsprogrammer wrote: post #18

Earlier quoted context omitted.

I've had a WebRTC app tested working under multiple OS's (Windows, Linux, Android) and browsers (Chrome, Firefox, IE, Chrome for Android). It did take more than a month to get to that point though.

Repo or it didn't happen.

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.

Re: A Study of WebRTC Security

#24

Post by juberti »

diafygi wrote: post #4

> "WebRTC is not designed with the intention of protecting a user from a malicious website which wants to learn this information [IP Address]. Typically, such a site will learn at least a user's server reflexive address from any HTTP transaction. Hiding the IP address from the server would require some kind of explicit privacy preserving mechanism on the client, and is out of scope of this report." This is very misle…

Current implementations of WebRTC, by default, only perform STUN over the default route (to address this exact situation).

See https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 for more details.

Re: A Study of WebRTC Security

#25

Post by dbrgn »

moron4hire wrote: post #14

It'd be one thing if WebRTC actually worked, then we could maybe talk about trade offs and whether or not the functionality is worth the negative impact. But WebRTC is a real shit-show right now. It's a 5 year old spec that doesn't have a single complete implementation, and no two implementations are even close to being reasonably compatible. I challenge any one person to write a WebRTC-utilizing app, from just the s…

Regarding the spec, it's not finished yet, so it's hard to write a "complete" implementation. In the browser, adapter.js https://github.com/webrtc/adapter should help a lot though.

Re: A Study of WebRTC Security

#26

Post by [deleted] »

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.

[deleted]

Re: A Study of WebRTC Security

#27

Post by moron4hire »

dbrgn wrote: post #25
moron4hire wrote: post #14

It'd be one thing if WebRTC actually worked, then we could maybe talk about trade offs and whether or not the functionality is worth the negative impact. But WebRTC is a real shit-show right now. It's a 5 year old spec that doesn't have a single complete implementation, and no two implementations are even close to being reasonably compatible. I challenge any one person to write a WebRTC-utilizing app, from just the s…

Regarding the spec, it's not finished yet, so it's hard to write a "complete" implementation. In the browser, adapter.js https://github.com/webrtc/adapter should help a lot though.

Five years is too long, and adapter.js is not very good.

Re: A Study of WebRTC Security

#28

Post by lgrahl »

Dowwie wrote: post #11
dbrgn wrote: post #6

Earlier quoted context omitted.

I agree. We're working on that: https://github.com/saltyrtc/saltyrtc-meta It's a signaling protocol based on NaCl with encryption, authentication, forward secrecy, protection against MITM and replay attacks, and with an additional (optional) encryption layer for WebRTC (and in the future also ORTC) data channels. It's not ready for real use yet, but a first release with a server written in Python and client libraries…

I noticed you are using asyncio. Check out the Asphalt framework.

Thanks for the hint! For now, we can't use Asphalt as it requires Python 3.5 and we're supporting Python 3.4+

Re: A Study of WebRTC Security

#29

Post by moron4hire »

jsprogrammer wrote: post #23
moron4hire wrote: post #22

Earlier quoted context omitted.

Repo or it didn't happen.

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.

Re: A Study of WebRTC Security

#30

Post by diafygi »

juberti wrote: post #24
diafygi wrote: post #4

> "WebRTC is not designed with the intention of protecting a user from a malicious website which wants to learn this information [IP Address]. Typically, such a site will learn at least a user's server reflexive address from any HTTP transaction. Hiding the IP address from the server would require some kind of explicit privacy preserving mechanism on the client, and is out of scope of this report." This is very misle…

Current implementations of WebRTC, by default, only perform STUN over the default route (to address this exact situation). See https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 for more details.

Thanks! That was super refreshing to read. I really hope it becomes required for default WebRTC behavior.
Post reply on HN