A Study of WebRTC Security • Hacker News Board

Re: A Study of WebRTC Security

#11

Post by Dowwie » Thu, Oct 20, 2016, 5:53 PM UTC

dbrgn wrote: post #6

dancek wrote: post #3

From a quick reading, it seems that the signaling protocol (which WebRTC doesn't specify) is the potential weakest link. The article gives the example of using SIP with plaintext packets easily intercepted and forged. One suggested remedy is using WSS instead, which I find strange as the status of WebSockets is quite unclear now with HTTP/2.

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.

Re: A Study of WebRTC Security

#12

Post by dom0 » Thu, Oct 20, 2016, 6:06 PM UTC

dbrgn wrote: post #6

dancek wrote: post #3

From a quick reading, it seems that the signaling protocol (which WebRTC doesn't specify) is the potential weakest link. The article gives the example of using SIP with plaintext packets easily intercepted and forged. One suggested remedy is using WSS instead, which I find strange as the status of WebSockets is quite unclear now with HTTP/2.

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'm glad that SIP has no footing here.

Re: A Study of WebRTC Security

#13

Post by tdurden » Thu, Oct 20, 2016, 8:05 PM UTC

"However, the open-source nature of the technology may have the potential to cause security-related concerns to potential adopters of the technology"

Seems odd to me that being open-source would cause security concerns...

Re: A Study of WebRTC Security

#14

Post by moron4hire » Thu, Oct 20, 2016, 8:46 PM UTC

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 spec, that works in two OSes and two browsers.

Add on to that the fact that none of the popular examples are running on anything resembling the latest version of the spec. It's complete garbage. I've stooped to having to use a third party framework in my project, and that still fails 20% of the time when it's not 100% of the time on iOS.

I lost at least month to WebRTC. They lure you in with the promise of working over your LAN and then completely destroy your dreams. I've had connections report they were successful and still have no audio come through! "Get a TURN server" they say. Did that, didn't help, still have problems because the STUN connections are reporting success so the TURN server is never attempted. No errors, no indication something is wrong. How are you supposed to recover from something like that?

Re: A Study of WebRTC Security

#15

Post by samsonradu » Thu, Oct 20, 2016, 10:30 PM UTC

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 fully agree with the above. Maintaining a live streaming website which still uses Flash unfortunately, I was really excited over this about a year ago until I saw that I can barely use our beta with my remote co-workers, different network setups are a pain. I stopped and sworn I ll never touch it until I see one of our bigger competitors adopting it. Seems not much has changed since.

Re: A Study of WebRTC Security

#16

Post by samsonradu » Thu, Oct 20, 2016, 10:42 PM UTC

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.

Re: A Study of WebRTC Security

#17

Post by Senji » Thu, Oct 20, 2016, 10:43 PM UTC

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.

Re: A Study of WebRTC Security

#18

Post by jsprogrammer » Thu, Oct 20, 2016, 11:58 PM UTC

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.

Re: A Study of WebRTC Security

#19

Post by faitswulff » Fri, Oct 21, 2016, 12:06 AM UTC

euyyn wrote: post #7

d33 wrote: post #2

TLDR penultimate paragraph of the conclusion: > As a result of this strong focus on secure communication, WebRTC is currently regarded by some to be one of the most secure VoIP solutions out there. The main premise of having encryption by default is that a call is private at all times. Security and encryption are no longer considered to be optional features. And to round everything off, WebRTC is available free to ev…

> And to round everything off, WebRTC is available free to everyone, providing a tempting and reliable framework for developers to build their next application. Is it me, or that doesn't have to do with security? Sounds like a sales pitch.

It's relevant because people, perhaps especially devs, are lazy and they'll optimize for minimizing workload instead of security.

Re: A Study of WebRTC Security

#20

Post by TD-Linux » Fri, Oct 21, 2016, 2:53 AM UTC

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.