
A Study of WebRTC Security - wanderer42
http://webrtc-security.github.io/
======
diafygi
> "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/](https://webrtchacks.com/dear-ny-
times/)

~~~
MichaelGG
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_.

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

------
moron4hire
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?

~~~
dbrgn
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](https://github.com/webrtc/adapter) should
help a lot though.

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

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

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

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

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

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

~~~
dbrgn
I agree. We're working on that: [https://github.com/saltyrtc/saltyrtc-
meta](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.

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

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

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

~~~
TD-Linux
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.

~~~
samsonradu
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...](http://doc-
kurento.readthedocs.io/en/stable/introducing_kurento.html#webrtc-media-
servers)

~~~
TD-Linux
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](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](https://janus.conf.meetecho.com/videoroomtest.html)

