chrome 49+ cannot get access from chrome 49+

[trevj]

Spotted while rolling the latest uproxy-lib release. 49 is canary right now. It can get access from any other Chrome version, and Firefox stable.

trevj@trevj1:~/src/uproxy-lib$ curl -x socks5h://0.0.0.0:9999 www.example.com
curl: (7) Unable to receive initial SOCKS5 response.

Getter logs:

zork [2016-01-08T21:51:30.161Z] listening on port 9000
zork [2016-01-08T21:51:30.433Z] N0.A1: new client from {"address":"172.17.0.1","port":44580}
zork [2016-01-08T21:51:30.915Z] N0.A1: closed (REMOTELY_CLOSED)
zork [2016-01-08T21:51:33.998Z] N1.A2: new client from {"address":"172.17.0.1","port":44650}
bridge [2016-01-08T21:51:33.999Z] sockstortc: negotiating, offering HOLO_ICE provider
churn [2016-01-08T21:51:34.006Z] sockstortc: transformer config: {"name":"caesar","config":"{\"key\":169}"}
PeerConnection [2016-01-08T21:51:34.088Z] sockstortc-probe: maximum number of channels now 1024
PeerConnection [2016-01-08T21:51:34.089Z] sockstortc-obfuscated: maximum number of channels now 1024
churn-pipe [2016-01-08T21:51:34.252Z] sockstortc: using caesar obfuscator
PeerConnection [2016-01-08T21:51:34.255Z] sockstortc-obfuscated: handling signal from peer: {"type":1,"description":{"type":"answer","sdp":"v=0\r\no=- 283156942066055753 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=msid-semantic: WMS\r\nm=application 9 DTLS/SCTP 5000\r\nc=IN IP4 0.0.0.0\r\nb=AS:30\r\na=ice-ufrag:U2WoPCrZnObpe1N1\r\na=ice-pwd:eneKwM+VfcdiqYKd1wm2Tf1t\r\na=fingerprint:sha-256 F8:F5:4A:75:91:01:26:1D:9E:EB:7B:C9:0A:BC:06:14:37:26:86:41:42:AE:57:97:E1:73:58:10:26:81:F3:58\r\na=setup:active\r\na=mid:data\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n"}}
PeerConnection [2016-01-08T21:51:34.271Z] sockstortc-obfuscated: handling signal from peer: {"type":2,"candidate":{"candidate":"candidate:3494562055 1 udp 2122260223 172.17.0.3 54262 typ host generation 0 ufrag GSEFsMh5ffBH/7aR","sdpMid":"data","sdpMLineIndex":0}}
PeerConnection [2016-01-08T21:51:34.272Z] sockstortc-obfuscated: handling signal from peer: {"type":2,"candidate":{"candidate":"candidate:862670827 1 udp 1686052607 172.17.0.3 47187 typ srflx raddr 172.17.0.4 rport 43479 generation 0 ufrag GSEFsMh5ffBH/7aR","sdpMid":"data","sdpMLineIndex":0}}
PeerConnection [2016-01-08T21:51:34.272Z] sockstortc-obfuscated: handling signal from peer: {"type":2,"candidate":{"candidate":"candidate:862670827 1 udp 1686052607 172.17.0.3 47760 typ srflx raddr 172.17.0.4 rport 43479 generation 0 ufrag GSEFsMh5ffBH/7aR","sdpMid":"data","sdpMLineIndex":0}}
churn [2016-01-08T21:51:36.965Z] sockstortc: probing timed out, closing probe connection
zork [2016-01-08T21:51:44.267Z] N1.A2: closed (REMOTELY_CLOSED)
SocksToRtc [2016-01-08T21:51:44.291Z] peerconnection terminated
zork [2016-01-08T21:51:44.292Z] N1.A2: failed to start SOCKS server: Connection lost: failed
SocksToRtc [2016-01-08T21:51:44.301Z] server socket closed: WE_CLOSED_IT
undefined:1 Uncaught (in promise) Object

Giver logs:

zork [2016-01-08T21:51:30.994Z] listening on port 9000
zork [2016-01-08T21:51:31.442Z] N0.A1: new client from {"address":"172.17.0.1","port":38232}
zork [2016-01-08T21:51:31.924Z] N0.A1: closed (REMOTELY_CLOSED)
zork [2016-01-08T21:51:33.958Z] N1.A2: new client from {"address":"172.17.0.1","port":38276}
churn [2016-01-08T21:51:34.032Z] rtctonet: transformer config: {"name":"caesar","config":"{\"key\":169}"}
PeerConnection [2016-01-08T21:51:34.053Z] rtctonet-probe: maximum number of channels now 1024
churn-pipe [2016-01-08T21:51:34.223Z] rtctonet: using caesar obfuscator
PeerConnection [2016-01-08T21:51:34.225Z] rtctonet-obfuscated: handling signal from peer: {"type":0,"description":{"type":"offer","sdp":"v=0\r\no=- 4271432075315347747 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=msid-semantic: WMS\r\nm=application 9 DTLS/SCTP 5000\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:f3LUTVEAppwVKonQ\r\na=ice-pwd:KsmPDH0WjdrC1Ke462BHD073\r\na=fingerprint:sha-256 25:77:4C:47:F5:7C:77:C3:35:BA:A3:97:4E:31:ED:7B:75:62:67:CF:14:2D:C3:8D:1E:A4:2E:45:A3:47:25:A3\r\na=setup:actpass\r\na=mid:data\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n"}}
PeerConnection [2016-01-08T21:51:34.237Z] rtctonet-obfuscated: maximum number of channels now 1024
PeerConnection [2016-01-08T21:51:34.249Z] rtctonet-obfuscated: handling signal from peer: {"type":2,"candidate":{"candidate":"candidate:1302196670 1 udp 2122260223 172.17.0.4 56167 typ host generation 0 ufrag HSu6DQLFQtiyBW+S","sdpMid":"data","sdpMLineIndex":0}}
PeerConnection [2016-01-08T21:51:34.250Z] rtctonet-obfuscated: handling signal from peer: {"type":2,"candidate":{"candidate":"candidate:2931586898 1 udp 1686052607 172.17.0.4 56463 typ srflx raddr 172.17.0.3 rport 32770 generation 0 ufrag HSu6DQLFQtiyBW+S","sdpMid":"data","sdpMLineIndex":0}}
PeerConnection [2016-01-08T21:51:34.250Z] rtctonet-obfuscated: handling signal from peer: {"type":2,"candidate":{"candidate":"candidate:2931586898 1 udp 1686052607 172.17.0.4 52356 typ srflx raddr 172.17.0.3 rport 32770 generation 0 ufrag HSu6DQLFQtiyBW+S","sdpMid":"data","sdpMLineIndex":0}}
churn [2016-01-08T21:51:37.003Z] rtctonet: probing timed out, closing probe connection
zork [2016-01-08T21:51:44.262Z] N1.A2: failed to start rtcToNet: %1 Connection lost: failed
undefined:1 Uncaught (in promise) Object
zork [2016-01-08T21:51:44.270Z] N1.A2: closed (WE_CLOSED_IT)

[bemasc]

I think I can reproduce this in the uproxy-lib integration tests. Only effects Churn!

[trevj]

Great to know. 49 is now beta so we need to look into this urgently.

[trevj]

And from testing uproxy-lib just now it seems the issue is only between Chrome 49+ and Chrome 49+...Firefox is just fine:
https://github.com/uProxy/uproxy-lib/releases/tag/v36.1.0

[bemasc]

Preliminary diagnosis:
This WebRTC change adds a new extension field to ICE candidates: ufrag. This includes the same value as in the SDP's a=ice-ufrag: line.

In Churn, the candidates are generated by the Probe connection, but passed to the Obfuscated connection (after replacing the IP and port with the mirror port). Most browsers ignore the new ufrag extension and don't generate it, but new Chrome does generate it, and also respects it if it is present. This causes each side to attempt to contact the other using the Probe connection's ufrag, and the STUN packets are dropped by the recipient due to having the wrong ufrag.

@trevj proposes to fix this by dropping all extensions, or all extensions other than a whitelist, because ufrag (and future unknown extensions) doesn't buy us anything right now. Eventually, we may decide to implement ICE restart, at which point we can revisit this question.