Protect connections between Brave and our Tor subprocess

[tildelowengrimm]

Connecting to a Tor subprocess (#12934) over TCP sockets isn't necessarily the safest way to control and use a critical browser component. How can we harden this? Are there OS-specific measures we could use?

[riastradh-brave]

[Copied from #12935.]

The Firefox-based Tor Browser does two things:

1. Uses port 9150 by default for socks, and 9151 by default for control, in contrast to the usual defaults, 9050 and 9051, respectively.
2. On systems that support it, uses local sockets instead of tcp sockets for both socks and control. (I didn't realize until today that the tor daemon even supported local sockets for socks.)

We should do both of these. The first is easy; the second will require teaching net/socket and net/proxy about local sockets for socks proxies.

Alternatively, we might let tor choose the port number, so that we don't conflict with either the Firefox-based Tor Browser's tor process or any other port number that any other process might be using.

With tor's ControlPort auto configuration, the ControlPortWriteToFile /path/to/foo option causes tor to write the port number it has chosen for the control port to /path/to/foo, which we could situate in the tor data directory under Brave's config directory. This is moot for Unix where we want to use a local socket anyway, but maybe it is useful for Windows.

For the SOCKS port, there's also SocksPort auto, but there seems to be no option corresponding to ControlPortWriteToFile, which is a little puzzling because I'm not sure how you're supposed to get the port number in that case -- I'm not seeing an obvious way to get it out of the control channel. For the SOCKS port, until brave/muon#469 is implemented, we do need to use a TCP/IP socket for SOCKS. Will ask upstream about this.

[riastradh-brave]

On the control channel, GETINFO net/listeners/socks can be used to find the socks port, if we use SocksPort auto.

[riastradh-brave]

ControlPortWriteToFile also writes any local socket addresses to the file, so it is tempting to try to use this to be notified of when the tor daemon is running by specifying a path to a named pipe...but it writes to a .tmp file first and renames over the permanent name, so that doesn't help for notification that the control socket is ready.

[riastradh-brave]

State of affairs:

• We use socks port 9250, 9260, 9270, or 9280 depending on what channel of release we're in (local build, developer, nightly, or beta).
• We let tor (or, really, the operating system) decide on the control port and notify is via ControlPortWriteToFile.
• There is logic to get the socks port via the control connection.
• However, it is not convenient to use that logic to configure what socks proxy we use.
• The logic to talk to the control connection will have to be rewritten in brave-core anyway, so it's not worth the effort to do anything further on using a system-chosen port number for socks until brave-core.

[riastradh-brave]

Superseded by:

• Use an OS-chosen port number for tor socks proxy brave-browser#649
• Use a local socket for tor socks proxy and control channel where available brave-browser#650