1285330 - Add TCP filtering which support STUN and HTTP

Status: NEW

(Core :: WebRTC: Networking, defect, P3)

Description

[Nils Ohlmeier [:drno]]

Bug 1244926 added a filter which only lets initially STUN packets out to prevent that if the content process has been compromised the attacker can open network connections to where ever he wants.
But when an HTTP proxy is configured in FF we first ask that proxy via HTTP CONNECT to connect us to the TURN TCP server (if one is provisioned by the WebRTC service).
So the filter needs to support plain ICE TCP connections (which exchange STUN packets with TCP framing right away). But also all kind of initial HTTP traffic to a proxy, e.g. HTTP CONNECT rejected with 407 and tried again with credentials for the proxy, until the proxy provides us with a working connection to the TURN server.

Ideas which came to my mind so far are:
A) If chrome tells us a proxy is configured we tell the filter to only let HTTP CONNECTS go out. Unfortunately we can't enforce a lot in this case as the proxy might be a DNS address and we therefore can't enforce e.g. the exact IP address of the proxy.
But since the address of the proxy is given to us from chrome I don't see how an attacker could provision us with a different proxy address. If the attacker could set the proxy address that would make the packet filter void, as he then simply could point us to any HTTP proxy under his control or open proxy on the Internet.
As we don't know how the HTTP protocol exchange is going to look like (in terms of how many requests and response or how many bites etc), we can't unfortunately enforce that STUN needs to exchanged once the proxy successfully connected FF to the potential TURN server.

B) Another option might be to try to remove the HTTP proxy code in nICEr and use the Necko HTTP client instead. Hopefully the Necko HTTP client actually runs in the e10s parent process. If that is the case then could simply ask the Necko HTTP client to request a connection from the proxy to the TURN server and get back to us in the child space in case of success or failure. In case of success we could then still enforce the existing TCP packet filter from bug 1244926.

Comment 1

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.