A Study of WebRTC Security
webrtc-security.github.io
A Study of WebRTC Security
1–10 of 38 posts
Re: A Study of WebRTC Security
#2TLDR 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.
Re: A Study of WebRTC Security
#3From 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.
Re: A Study of WebRTC Security
#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 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).
Re: A Study of WebRTC Security
#5[deleted]
Re: A Study of WebRTC Security
#6From 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.
Re: A Study of WebRTC Security
#7TLDR 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.
Re: A Study of WebRTC Security
#8> "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…
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.
Re: A Study of WebRTC Security
#9> "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…
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.
Re: A Study of WebRTC Security
#10TLDR 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.
[deleted]