WebRTC: Not Quite Magic

#1

Post by alexfreska » Sun, Mar 30, 2014, 3:58 PM UTC

Re: WebRTC: Not Quite Magic

#2

Post by jmspring » Sun, Mar 30, 2014, 4:47 PM UTC

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.

Re: WebRTC: Not Quite Magic

#3

Post by abhilash0505 » Sun, Mar 30, 2014, 4:55 PM UTC

http://community.igniterealtime.org/blogs/ignite/2013/11/28/... I have used this in the past.

Re: WebRTC: Not Quite Magic

#4

Post by kodablah » Sun, Mar 30, 2014, 4:58 PM UTC

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.

Re: WebRTC: Not Quite Magic

#5

Post by alexfreska » Sun, Mar 30, 2014, 5:14 PM UTC

kodablah wrote: post #4

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 mechani…

Interesting, yes I agree, as much should be exposed as possible to interface with any creative fallbacks people come up with for their system.

Re: WebRTC: Not Quite Magic

#6

Post by higherpurpose » Sun, Mar 30, 2014, 5:14 PM UTC

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?

Re: WebRTC: Not Quite Magic

#7

Post by mike__t » Sun, Mar 30, 2014, 5:15 PM UTC

kodablah wrote: post #4

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 mechani…

Turn servers can also send data over TCP (e.g. 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.

Re: WebRTC: Not Quite Magic

#8

Post by caio1982 » Sun, Mar 30, 2014, 5:18 PM UTC

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?

Re: WebRTC: Not Quite Magic

#9

Post by alexfreska » Sun, Mar 30, 2014, 5:21 PM UTC

higherpurpose wrote: post #6

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?

Some of the security is explained in an overview at Google IO. Here is a video: http://youtu.be/p2HzZkd2A40?t=22m18s

Re: WebRTC: Not Quite Magic

#10

Post by kodablah » Sun, Mar 30, 2014, 5:25 PM UTC

mike__t wrote: post #7

kodablah wrote: post #4

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 mechani…

Turn servers can also send data over TCP (e.g. 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.

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-... 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=891551 3 - https://bugzilla.mozilla.org/show_bug.cgi?id=906968