Sanitize "tor:" endpoint options

[meejah]

As per comments in #104 and on Foolscap, at least the SOCKS host from "tor:" endpoint strings should be sanitized to be local-only. Possibly not as restrictive as 127.0.0.0/8 in case people have a separate anonymizing box in their network, but certainly should restrict to private-network only addresses.

[nathan-at-least]

The problem with this approach is that it's the end-user that should decide on the policy, not a library or an application. For example, having a Tor SOCKS proxy on a different IP may be common for isolation purposes.

I almost want to advocate removing SOCKS host/port from the endpoint parser altogether, but then the endpoint needs to get this information from elsewhere, and where would that be? (That seems application specific.) Maybe environment variables would be general enough for almost all applications.

[meejah]

Personally, I like (drastically) limiting the options available from the endpoint strings.

Currently with txtorcon, you can access the "global" tor instance's configuration via "get_global_tor()". It's kind of hacky/whatever-I-thought-of-first but it is possible. The point of this was to allow people using the "onion:" endpoint API to set their favourite weird options, but not expose them into the endpoint parser. This isn't tied into the current client-endpoint branch's implementation, but certainly could be, or something along those lines. (IOW, an app that wants to connect to non-default SOCKS ports would call some txtorcon API first, then .connect() their endpoint. This could be exposed in the endpoint object that's returned, for example).

The other way to look at it is that the endpoint-strings should be super-simple and fairly safe. If you want to SOCKS to another internet-connected host, then you can build your own TorClientEndpoint and you own all the pieces ;) when it goes sideways.

(I believe the Twisted intension is that you expose these endpoint strings to the user -- certainly they have in twistd -- so limiting the foot-gun potential is a good idea, IMO).

I will think about this more, especially in regards to the "best effort" construction of a connection to Tor...