5 ms·

WebRTC: Not Quite Magic

120 points by alexfreska 12y ago

jmspring 12y ago
Signaling and NAT traversal are two interesting pieces, as outlined. It can get even more involved if you want to use peer identity and authenticate against an IDP. WebRTC is still in draft stage and browser implementations are still writing more code. That said, it does provide a platform for interesting apps. On a related note - I am curious how many people will use WebRTC directly or wrappers like those provided by twilio and similar.
abhilash0505 12y ago
http://community.igniterealtime.org/blogs/ignite/2013/11/28/jitsi-videobridge-with-openfire-and-webrtc http://community.igniterealtime.org/blogs/ignite/2013/11/28/... I have used this in the past.
kodablah 12y ago
I agree this is a problem. From what I understand SCTP can be TCP and is more reliable but cannot be proxied via a TURN server since it's UDP only. I am experimenting with WebRTC and I built a fallback over websockets but I find myself encrypting the data client side to avoid trust issues because I don't have access to the encryption mechanisms baked into WebRTC. I think there needs to be a pluggable fallback mechanism when all the ICE servers are exhausted.
- alexfreska 12y ago
  Interesting, yes I agree, as much should be exposed as possible to interface with any creative fallbacks people come up with for their system.
- mike__t 12y ago
  Turn servers can also send data over TCP (e.g. https://code.google.com/p/rfc5766-turn-server/ https://code.google.com/p/rfc5766-turn-server/ does). The browser also needs to support this option as well; Chrome seems to with a ";transport=tcp" at the send of the turn server configuration url.
  - kodablah 12y ago
    My mistake, I see that now [1]. It seems both sides need to specify that which isn't a problem. Also seems FF is on board [2][3]. 1 - https://groups.google.com/forum/#!topic/turn-server-project-rfc5766-turn-server/vR_2OAV9a_w https://groups.google.com/forum/#!topic/turn-server-project-... 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=891551 https://bugzilla.mozilla.org/show_bug.cgi?id=891551 3 - https://bugzilla.mozilla.org/show_bug.cgi?id=906968 https://bugzilla.mozilla.org/show_bug.cgi?id=906968
higherpurpose 12y ago
I'm interested in the security of WebRTC. Is it end to end? Can it be easily MITMed? What are its main flaws from a security design point of view?
- alexfreska 12y ago
  Some of the security is explained in an overview at Google IO. Here is a video: http://youtu.be/p2HzZkd2A40?t=22m18s http://youtu.be/p2HzZkd2A40?t=22m18s
- lallysingh 12y ago
  It's end-to-end, but you need a way to validate that you're talking to the peer that you think that you are - there's no certificate authority verifying client certs (in the normal case, I haven't explored traditional client-side certs for webrtc).
- jmspring 12y ago
  Eric Rescorla does a good job of describing the security architecture and concerns around webrtc here: http://tools.ietf.org/id/draft-ietf-rtcweb-security-arch-09.txt http://tools.ietf.org/id/draft-ietf-rtcweb-security-arch-09.... and http://tools.ietf.org/id/draft-ietf-rtcweb-security-06.txt http://tools.ietf.org/id/draft-ietf-rtcweb-security-06.txt
- wbl 12y ago
  It's still a work in progress. Right now if you trust the service to connect you to the right person, everything works out. However, they aim to make things work even if you don't, and the jury is still out about whether or not they can make a UI that reflects this safely. Furthermore, there are some anonymity issues related to the use of RSA to secure the SRTP connections. The identity provider portion involves trying to sandbox javascript in new and interesting ways. However, most of the pieces are fairly well understood, and the breaks will happen because identity providers mess up.
- ryanseys 12y ago
  I worked as an intern with Mozilla last summer on helping to improve the issues around security in WebRTC specifically related to authentication and the possibility of MITM attacks. You can watch my intern presentation at [1] which goes through a very high level overview of the state of authentication in WebRTC and an example implementation of how WebRTC could be built into the browser to include authentication: [1]: https://air.mozilla.org/intern-presentation-seys/ https://air.mozilla.org/intern-presentation-seys/ TLDR: E2E encryption is included, but authentication is currently non-existent, allowing for pretty easy MITM attacks if you have control of the relaying website.
caio1982 12y ago
While I think WebRTC is so fantastic it's nearly magical, I find it incredible how people using/creating it overlook networks' topologies problems that SIP and other VoIP folks already had to deal with (and went crazy doing so) a whole decade ago. NAT issues, STUN, all that is long known and yet I've never seen a fully working solution for peer-to-peer communication that won't be stopped by the simplest firewalls. Does anyone know any other "fix" for these kind of scenario as described in the post?
- sktrdie 12y ago
  I think that's the whole point of firewalls, to control incoming and outgoing connections. So peer-to-peer sometimes is simply impossible. TURN actually is just a proxy as far as I know so it's not p2p. That's why BitTorrent asks to open specific ports in your router, because otherwise you simply can't do p2p.
- rdtsc 12y ago
  Because of low barrier to entry people who didn't learn about jitter, network latencies, BSD sockets, etc. That is the promise of WebRTC -- just a few lines of JS and you've got yourself Google- Hangouts. One can argue this happens in web frameworks and other technologies that make it easy to get started with, which is a good thing. But unfortunately a lot of these easy abstractions can't completely abstract away things like speed of light latencies, limitation of network bandwidth, funky NAT setups and so on. So far there are very few peer peer technologies that work reliably and are successful.
- cpncrunch 12y ago
  The problem is that peer-to-peer isn't a very efficient way of doing group video chat to begin with...much better and simpler to just use a central server in that case.
  - makomk 12y ago
    Yeah. Sadly, in order to protect users against servers MITMing their video chats, the WebRTC spec was crippled to require that the central server in a group video chat have the keys required to MITM it. I'm unfortunately not joking. The original spec allowed Javascript to directly provide an encryption key; this was removed because someone working for one of the browser vendors argued it would allow companies to MITM video chat (I think it was Google?) In order to make group video chat feasible, this was then replaced with a new feature where the central server sent out a copy of the encryption key over the encrypted RTP channel, meaning it now needed to have the keys to decrypt all the video passing through it.
AshleysBrain 12y ago
As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use NAT, and either ignored peer-to-peer connections or went ahead and broke them anyway. This makes innovation with peer-to-peer tech more difficult and expensive, because now to get things working for everyone you need to configure additional relay servers and pay for the bandwidth of everyone who needs to use it. That could rule out some services being made free and could mean the extra cost being passed on to customers when it could have just run through their ISPs. I think the solution is IPv6. Once every device on the Internet is uniquely addressable again, we can do away with these NAT hacks and two endpoints should be able to reliably connect to each other again, no matter where they are. Of course, that's assuming we don't get more short-sighted engineering that breaks things again...
- alexfreska 12y ago
  Yeah IPv6 is valuable but it seems NAT is the smallest inconvenience since a p2p connection can usually still be made. Briefly giving it thought, I don't think IPv6 could rid the use of TURN servers or close the other 5% of anomalies. Am I wrong?
  - AshleysBrain 12y ago
    NAT only exists to workaround IPv4 address exhaustion. I think it's more likely the 5% edge cases have firewalls that block anything that doesn't look like normal HTTP traffic.
    - rictic 12y ago
      I don't think that's so. A NAT also prevents random hosts from directly opening connections to the machines that it's obfuscating (module port forwarding), which serves a nice security purpose.
deleted 12y ago
[deleted]
bruun 12y ago
Tip if you feel like you have to maintain a lot of infrastructure with your TURN server: You can scrap your STUN server, since TURN is an extension of STUN. The TURN server will produce the same server reflex candidate as your STUN server. What port(s) were you using on your TURN server endpoint? Keep in mind that port 80 is often filtered, and many corporate networks often block non-HTTP(S) ports. At the WebRTC-utilizing service https://appear.in https://appear.in, we have found that using port 443 plays nicely with most restrictive networks.
- bryanpaluch 12y ago
  TURN over port 443 specifically using TCP not UDP should get around most firewalls. If a provider is using DPI and trying to disable ssl network wide, you will still have a problem.
penguindev 12y ago
I don't think even ipv6 without nat would guarantee 100% (not that we can count on ipv6 coverage in the next decade anyway). 1. Stateful IPV6 firewalls still need hole punching to connect peers, thus a stun server. 2. Think about a corporate network with complex routes and potentially multiple firewalls (for load balancing or route optimization). No guarantee you use the same gateway to get to the stun server and the other peer. Thus, punching fails. At least that's my uneducated guess. PS there's nat for ipv6 too (linux supports it). Misery is not going to end.

120 points by alexfreska 12y ago

Signaling and NAT traversal are two interesting pieces, as outlined. It can get even more involved if you want to use peer identity and authenticate against an IDP. WebRTC is still in draft stage and browser implementations are still writing more code. That said, it does provide a platform for interesting apps. On a related note - I am curious how many people will use WebRTC directly or wrappers like those provided by twilio and similar.

abhilash0505 12y ago

http://community.igniterealtime.org/blogs/ignite/2013/11/28/jitsi-videobridge-with-openfire-and-webrtc http://community.igniterealtime.org/blogs/ignite/2013/11/28/... I have used this in the past.

kodablah 12y ago

I agree this is a problem. From what I understand SCTP can be TCP and is more reliable but cannot be proxied via a TURN server since it's UDP only. I am experimenting with WebRTC and I built a fallback over websockets but I find myself encrypting the data client side to avoid trust issues because I don't have access to the encryption mechanisms baked into WebRTC. I think there needs to be a pluggable fallback mechanism when all the ICE servers are exhausted.

alexfreska 12y ago
Interesting, yes I agree, as much should be exposed as possible to interface with any creative fallbacks people come up with for their system.
mike__t 12y ago
Turn servers can also send data over TCP (e.g. https://code.google.com/p/rfc5766-turn-server/ https://code.google.com/p/rfc5766-turn-server/ does). The browser also needs to support this option as well; Chrome seems to with a ";transport=tcp" at the send of the turn server configuration url.
- kodablah 12y ago
  My mistake, I see that now [1]. It seems both sides need to specify that which isn't a problem. Also seems FF is on board [2][3]. 1 - https://groups.google.com/forum/#!topic/turn-server-project-rfc5766-turn-server/vR_2OAV9a_w https://groups.google.com/forum/#!topic/turn-server-project-... 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=891551 https://bugzilla.mozilla.org/show_bug.cgi?id=891551 3 - https://bugzilla.mozilla.org/show_bug.cgi?id=906968 https://bugzilla.mozilla.org/show_bug.cgi?id=906968

higherpurpose 12y ago

I'm interested in the security of WebRTC. Is it end to end? Can it be easily MITMed? What are its main flaws from a security design point of view?

alexfreska 12y ago
Some of the security is explained in an overview at Google IO. Here is a video: http://youtu.be/p2HzZkd2A40?t=22m18s http://youtu.be/p2HzZkd2A40?t=22m18s
lallysingh 12y ago
It's end-to-end, but you need a way to validate that you're talking to the peer that you think that you are - there's no certificate authority verifying client certs (in the normal case, I haven't explored traditional client-side certs for webrtc).
jmspring 12y ago
Eric Rescorla does a good job of describing the security architecture and concerns around webrtc here: http://tools.ietf.org/id/draft-ietf-rtcweb-security-arch-09.txt http://tools.ietf.org/id/draft-ietf-rtcweb-security-arch-09.... and http://tools.ietf.org/id/draft-ietf-rtcweb-security-06.txt http://tools.ietf.org/id/draft-ietf-rtcweb-security-06.txt
wbl 12y ago
It's still a work in progress. Right now if you trust the service to connect you to the right person, everything works out. However, they aim to make things work even if you don't, and the jury is still out about whether or not they can make a UI that reflects this safely. Furthermore, there are some anonymity issues related to the use of RSA to secure the SRTP connections. The identity provider portion involves trying to sandbox javascript in new and interesting ways. However, most of the pieces are fairly well understood, and the breaks will happen because identity providers mess up.
ryanseys 12y ago
I worked as an intern with Mozilla last summer on helping to improve the issues around security in WebRTC specifically related to authentication and the possibility of MITM attacks. You can watch my intern presentation at [1] which goes through a very high level overview of the state of authentication in WebRTC and an example implementation of how WebRTC could be built into the browser to include authentication: [1]: https://air.mozilla.org/intern-presentation-seys/ https://air.mozilla.org/intern-presentation-seys/ TLDR: E2E encryption is included, but authentication is currently non-existent, allowing for pretty easy MITM attacks if you have control of the relaying website.

caio1982 12y ago

While I think WebRTC is so fantastic it's nearly magical, I find it incredible how people using/creating it overlook networks' topologies problems that SIP and other VoIP folks already had to deal with (and went crazy doing so) a whole decade ago. NAT issues, STUN, all that is long known and yet I've never seen a fully working solution for peer-to-peer communication that won't be stopped by the simplest firewalls. Does anyone know any other "fix" for these kind of scenario as described in the post?

sktrdie 12y ago
I think that's the whole point of firewalls, to control incoming and outgoing connections. So peer-to-peer sometimes is simply impossible. TURN actually is just a proxy as far as I know so it's not p2p. That's why BitTorrent asks to open specific ports in your router, because otherwise you simply can't do p2p.
rdtsc 12y ago
Because of low barrier to entry people who didn't learn about jitter, network latencies, BSD sockets, etc. That is the promise of WebRTC -- just a few lines of JS and you've got yourself Google- Hangouts. One can argue this happens in web frameworks and other technologies that make it easy to get started with, which is a good thing. But unfortunately a lot of these easy abstractions can't completely abstract away things like speed of light latencies, limitation of network bandwidth, funky NAT setups and so on. So far there are very few peer peer technologies that work reliably and are successful.
cpncrunch 12y ago
The problem is that peer-to-peer isn't a very efficient way of doing group video chat to begin with...much better and simpler to just use a central server in that case.
- makomk 12y ago
  Yeah. Sadly, in order to protect users against servers MITMing their video chats, the WebRTC spec was crippled to require that the central server in a group video chat have the keys required to MITM it. I'm unfortunately not joking. The original spec allowed Javascript to directly provide an encryption key; this was removed because someone working for one of the browser vendors argued it would allow companies to MITM video chat (I think it was Google?) In order to make group video chat feasible, this was then replaced with a new feature where the central server sent out a copy of the encryption key over the encrypted RTP channel, meaning it now needed to have the keys to decrypt all the video passing through it.

AshleysBrain 12y ago

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use NAT, and either ignored peer-to-peer connections or went ahead and broke them anyway. This makes innovation with peer-to-peer tech more difficult and expensive, because now to get things working for everyone you need to configure additional relay servers and pay for the bandwidth of everyone who needs to use it. That could rule out some services being made free and could mean the extra cost being passed on to customers when it could have just run through their ISPs. I think the solution is IPv6. Once every device on the Internet is uniquely addressable again, we can do away with these NAT hacks and two endpoints should be able to reliably connect to each other again, no matter where they are. Of course, that's assuming we don't get more short-sighted engineering that breaks things again...

alexfreska 12y ago
Yeah IPv6 is valuable but it seems NAT is the smallest inconvenience since a p2p connection can usually still be made. Briefly giving it thought, I don't think IPv6 could rid the use of TURN servers or close the other 5% of anomalies. Am I wrong?
- AshleysBrain 12y ago
  NAT only exists to workaround IPv4 address exhaustion. I think it's more likely the 5% edge cases have firewalls that block anything that doesn't look like normal HTTP traffic.
  - rictic 12y ago
    I don't think that's so. A NAT also prevents random hosts from directly opening connections to the machines that it's obfuscating (module port forwarding), which serves a nice security purpose.

deleted 12y ago

[deleted]

bruun 12y ago

Tip if you feel like you have to maintain a lot of infrastructure with your TURN server: You can scrap your STUN server, since TURN is an extension of STUN. The TURN server will produce the same server reflex candidate as your STUN server. What port(s) were you using on your TURN server endpoint? Keep in mind that port 80 is often filtered, and many corporate networks often block non-HTTP(S) ports. At the WebRTC-utilizing service https://appear.in https://appear.in, we have found that using port 443 plays nicely with most restrictive networks.

bryanpaluch 12y ago
TURN over port 443 specifically using TCP not UDP should get around most firewalls. If a provider is using DPI and trying to disable ssl network wide, you will still have a problem.

penguindev 12y ago

I don't think even ipv6 without nat would guarantee 100% (not that we can count on ipv6 coverage in the next decade anyway). 1. Stateful IPV6 firewalls still need hole punching to connect peers, thus a stun server. 2. Think about a corporate network with complex routes and potentially multiple firewalls (for load balancing or route optimization). No guarantee you use the same gateway to get to the stun server and the other peer. Thus, punching fails. At least that's my uneducated guess. PS there's nat for ipv6 too (linux supports it). Misery is not going to end.