
WebRTC: Not Quite Magic - alexfreska
http://alexfreska.com/webrtc-not-quite-magic
======
AshleysBrain
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...

~~~
simon_vetter
Work is in progress to make webrtc implementations work over ipv6 but it's not
ready yet. Chrome 34 will implement it behind a feature flag (googIPv6:true)
[1], and hopefully Firefox will follow suit.

When they do, most pain points caused by NATs will go away, and that's not
webrtc specific. While you'll always encounter some (intentionally?) broken
network which only allows 80/tcp and 443/tcp from time to time, there's not
much you can do about it, and webrtc can't do much about it.

[1]
[http://code.google.com/p/webrtc/issues/detail?id=1406](http://code.google.com/p/webrtc/issues/detail?id=1406)

~~~
jmspring
> When they do, most pain points caused by NATs will go away, and that's not
> webrtc specific.

This is a naive statement since it assumes IPv6 support amongst the clients.
At least here in the US, such support is fairly minuscule.

~~~
ay
In the US, today, one in 15 clients accessing google.com / yahoo.com /
facebook.com is doing it from an IPv6 address.

And it's more than double compared to a year ago [1].

While indeed this still qualifies as "relatively small", I think it grew out
of the "miniscule" :-)

[1]
[http://6lab.cisco.com/stats/cible.php?country=US](http://6lab.cisco.com/stats/cible.php?country=US)

~~~
jmspring
I think mobile operators are going to drive the near term biggest uptick in
ipv6 adoption.

My local ISP (small, independent) has no current IPV6 plans, which is actually
a little bit annoying.

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

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

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

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

~~~
mike__t
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
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-...](https://groups.google.com/forum/#!topic/turn-server-project-
rfc5766-turn-server/vR_2OAV9a_w) 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
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?

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

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

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

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

