churn doesn't work between chrome and firefox

[trevj]

Simple SOCKS with churn works fine, but not uProxy. Seems to be just Firefox, and it seems to be related to the timing of ICE candidates: the obfuscated connection times out while the probe connection is still generating signalling messages. Weird!

However, this happens even if I specify no STUN servers -- there's clearly more going on here.

[bemasc]

The first issue I found is that onicecandidate(null) (indicating the end of gathering) can be greatly delayed in Firefox, firing later than the 5 second timeout for receiving the first ICE candidate. This causes the obfuscated connection go to the "failed" state.

After introducing a workaround (a 3 second timer to stop waiting for onicecandidate(null)) the connection still doesn't work, even when connecting to an external host (to avoid hairpinning issues). I'm not sure why it still doesn't work. This time, the connection fails when our own timeout kills SocksToRtc.

[trevj]

Have been digging into this. Firefox -> Firefox works just fine, as does Chrome -> Chrome.

There's something about the way we mangle candidate lines that is incompatible with how Chrome produces them, and how Firefox consumes them.

So far, I've tried a few things:

1. have churn-pipe explicitly bind to 127.0.0.1
2. send only one candidate line to the underlying (obfuscated) peerconnection

Not much success yet, though.

[trevj]

Oh, another thing: the set of STUN servers specified by uProxy takes ~10 seconds to complete gathering on Chrome. We need to dig into this, too. Reckon there'll be several things required to fix this.

[trevj]

So, Firefox doesn't like to act as a prflx candidate on 127.0.0.1.

Specifically, if WebRTC A (on Firefox) is communicating with a WebRTC B who reports A's address as 127.0.0.1 then Firefox's WebRTC A will not establish a connection with B. Wireshark can be used to identify this issue: you will see STUN messages with XOR-MAPPED-ADDRESS of 127.0.0.1 passed back to Firefox's WebRTC port.

With the current code, this happens when a uProxy running under Firefox attempts to connect with uProxy running on Chrome. Chrome respects the 127.0.0.1 supplied to churn-pipe but it turns out freedom-for-firefox always binds to *:
https://github.com/freedomjs/freedom-for-firefox/blob/master/providers/core.udpsocket.js#L13

If I change that second argument to init to true, then Simple SOCKS on Firefox no longer works.

The easiest fix is to have churn-pipe bind to a non-127.0.0.1 address; we can just bind to the same address/interface as the obfuscated WebRTC connection. For bonus points (extra security, for those having public IPs) the pipe really should only accept packets from the obfuscated WebRTC connection's address and port.

[bemasc]

The easiest fix is to have churn-pipe bind to a non-127.0.0.1 address

Well, as you pointed out, it looks like our implementation of bind in Firefox ignores this address anyway. Do we have to fix that first?

[trevj]

We may not need any fix on the Firefox side -- AFAICT, calling init with second argument false means "bind to all interfaces":
https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsUDPSocket.cpp#762

[bemasc]

Right. Is it then guaranteed that packets sent to some interface will see that same interface as the source address? I'm not aware of any such guarantee. AFAIK, the implementation could still set the source address to localhost.

[trevj]

A little more info on INADDR_ANY:

• http://www.cs.cmu.edu/~srini/15-441/F01.full/www/assignments/P2/htmlsim_split/node18.html
• http://stackoverflow.com/questions/16508685/understanding-inaddr-any-for-socket-programming-c

Right, I see no guarantee that your source address for packets won't be 127.0.0.1 -- but Wireshark tells me this isn't happening right now. I will file an issue to investigate further.

[trevj]

Let's:

• file an issue for freedom-for-firefox to actually bind to the requested address (right now for me it's fine but there's no guarantee that's true everywhere)
• bind mirror ports to 0.0.0.0 (I just tested this, seems to work nicely)
• have mirror ports accept traffic only from WebRTC

[bemasc]

OK, filed freedom-for-firefox issue: freedomjs/freedom-for-firefox#67

[trevj]

And the fix to bind to 0.0.0.0:
UWNetworksLab/uProxy-lib#196

[bemasc]

We now understand that this is a deliberate choice in Firefox, albeit not one that was deliberated at great length. It's possible that we could get a change to Firefox's behavior here, but given that Firefox 38 will be the Extended Support Release for two years, I think it behooves us to focus on making our code work in that version.

For context see the chat log on this topic.

[trevj]

I think this is the major outstanding TODO:
#1631