7 ms·

A Study of WebRTC Security

90 points by wanderer42 10y ago

d33 10y ago
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 10y ago
  > 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.
  - deleted 10y ago
    [deleted]
  - faitswulff 10y ago
    It's relevant because people, perhaps especially devs, are lazy and they'll optimize for minimizing workload instead of security.
dancek 10y ago
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 10y ago
  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 10y ago
    I noticed you are using asyncio. Check out the Asphalt framework.
    - lgrahl 10y ago
      Thanks for the hint! For now, we can't use Asphalt as it requires Python 3.5 and we're supporting Python 3.4+
  - dom0 10y ago
    I'm glad that SIP has no footing here.
diafygi 10y ago
> "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 10y ago
  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 10y ago
    > 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.
- juberti 10y ago
  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 https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 for more details.
deleted 10y ago
[deleted]
tdurden 10y ago
"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...
moron4hire 10y ago
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?
- samsonradu 10y ago
  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.
- Senji 10y ago
  Send a sinewave outside the human hearing range and check for it on both ends.
  - moron4hire 10y ago
    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.
samsonradu 10y ago
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 10y ago
  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 10y ago
    [deleted]
  - samsonradu 10y ago
    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_kurento.html#webrtc-media-servers http://doc-kurento.readthedocs.io/en/stable/introducing_kure...
    - TD-Linux 10y ago
      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

90 points by wanderer42 10y ago

d33 10y ago

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 10y ago
> 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.
- deleted 10y ago
  [deleted]
- faitswulff 10y ago
  It's relevant because people, perhaps especially devs, are lazy and they'll optimize for minimizing workload instead of security.

dancek 10y ago

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 10y ago
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 10y ago
  I noticed you are using asyncio. Check out the Asphalt framework.
  - lgrahl 10y ago
    Thanks for the hint! For now, we can't use Asphalt as it requires Python 3.5 and we're supporting Python 3.4+
- dom0 10y ago
  I'm glad that SIP has no footing here.

diafygi 10y ago

> "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 10y ago
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 10y ago
  > 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.
juberti 10y ago
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 https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 for more details.

deleted 10y ago

[deleted]

tdurden 10y ago

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

moron4hire 10y ago

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?

samsonradu 10y ago
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.
Senji 10y ago
Send a sinewave outside the human hearing range and check for it on both ends.
- moron4hire 10y ago
  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.

samsonradu 10y ago

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 10y ago
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 10y ago
  [deleted]
- samsonradu 10y ago
  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_kurento.html#webrtc-media-servers http://doc-kurento.readthedocs.io/en/stable/introducing_kure...
  - TD-Linux 10y ago
    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