[tor-bugs] #11010 [Tor]: add ClientConnectPolicy config option

[Tor Bug Tracker & Wiki]

#11010: add ClientConnectPolicy config option
-----------------------------+--------------------------------
     Reporter:  cypherpunks  |      Owner:
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-client
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------------

Comment (by cypherpunks):

 Replying to [comment:7 nickm]:
 > Hm.  After looking at this, I don't think I understand why you're doing
 this with full addresses, and not just ports.

 I mostly want this feature for port-based policies, but I included IP
 address support too because the policy parser does it already (so it was
 easy) and also because I think address-based policies might actually be
 useful in some cases. For instance, say I've got an system that I expect
 should only connect to 1.2.3.4:22 without using a hostname, I could have a
 ClientConnectPolicy of "accept 1.2.3.4:22, reject *:*". Attempts to
 connect to hostnames that resolve to 1.2.3.4 will be rejected, but
 connections to the IP will be allowed.

 I'd rather have hostname support too, but this would be complicated
 because (a) the policy parser would need to support hostnames, and (b)
 applying IP-based policies to hostname-based connections isn't really
 possible due to what you say below. So, I figured that documenting
 ''Connections using hostnames will only be matched by policies with "*" as
 their IP address'' was a reasonable middle ground. Perhaps that could be
 said in a clearer way?

 > In other words, if the user allows "1.2.3.4/80", and then Tor receives a
 SOCKS connection for "www.example.com:80", should the code allow the
 request to be made or not?  Keep in mind that a BEGIN cell does a lookup
 and a connect in one step: Tor won't know whether www.example.com resolved
 to 1.2.3.4 until the connection is made.  With this patch, I think the
 answer will depend on whether the user said to allow 0.0.0.0, which can't
 really be the right behavior.

 Correct, but I did think that would be OK behavior if sufficiently
 documented (which perhaps it isn't).

 > Given that address-based rules don't work the way that users might
 expect here, are we losing anything important by having this be address-
 and-port based rather than port-based alone?

 I assume you mean the opposite, would we losing anything by having this be
 port based alone? We'd just be losing the ability to have IP-based
 policies which don't apply to hostname-based connections. That
 functionality was not my primary objective, but I do think it could be
 useful in some cases.

 Let me know if you think the docs should/could be clarified about this, or
 if you want me to make a solely port-based version of the patch.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11010#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online