A Study of WebRTC Security | Hacker News Reader

A Study of WebRTC Security

webrtc-security.github.io

90 pointswanderer4234 comments

> "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 misleading. Anonymous VPN users (China, Australia, etc.) don't care about hiding their VPN IP. They care about hiding their real IP.

Unfortunately, the default setup for WebRTC in browsers is to try STUN over _all_ network interfaces, which for default VPN setups on Windows, OSX, and Linux means sending packets outside of the VPN (which leaks your real IP!).

Also unfortunately, triggering the STUN doesn't require user consent, so all it takes is to visit a webpage and you've leaked your real IP[1].

This can literally be deadly default behavior. WebRTC needs to either only perform STUN over the default route, or STUN needs to be behind user opt-in consent (just like getUserMedia).

https://webrtchacks.com/dear-ny-times/

Yep. WebRTC data on by default, no prompt or restrictions, is a mistake. I understand prompts aren't a solution to everything, but silent data channels don't have a good use case yet, so it's an unnecessary risk.

It also breaks user specified preferences and expected behaviour: if I specify that my browser should use a proxy, it should use it.

> WebRTC data on by default, no prompt or restrictions, is a mistake.

If webrtc just performed the expected behavior seems like it wouldn't be an issue.

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.

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?

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.

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.

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.

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.

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?

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.

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

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 everyone, providing a tempting and reliable framework for developers to build their next application.

> 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.

"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...

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 for JavaScript and Java should be ready in the next weeks.

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+

I'm glad that SIP has no footing here.

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...

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

Reply on news.ycombinator.com