[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3982 [Tor Client]: MAPADDRESS for IP ranges (CIDR, etc)
#3982: MAPADDRESS for IP ranges (CIDR, etc)
-------------------------+--------------------------------------------------
Reporter: grarpamp | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Tor: 0.2.3.x-final
Component: Tor Client | Version: Tor: 0.2.2.32
Keywords: | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by grarpamp):
> So, if somebody configured this, they couldn't use any BEGIN cells
> with a hostname in them?
Couldn't? They could, but the result might be unexpected.
> But if you've set things up so that 38.229.70.0/8 gets remapped
> to something else, then now it's too late: you already made a
> connection to 38.299.70.16 when you connected to www.torproject.org.
If your only connection requests are for tpo, yes.
0) And, also today, if I have only a map for the IP, the first
connect to the FQDN appears not to check that map :( Of course due
to the responsibilities of the exit and these cells as you mentioned.
Future connects do check it, presumably since the IP returned from
CONNECTED is now loaded into the local client state.
Looks like I'm wrong in thinking Tor operates like standard DNS...
ie: client requests connect to www, wait while path opens for DNS
and some exit resolves it, client receives reply of 38, client sends
packet to 38, buffer as some (possibly new) path opens up for that
too, packet moves on through.
Underlying the proposal, I figured...
1) *.domain maps would be independant from CIDR maps:
map tpo a.exit
map 38 b.exit
telnet tpo (uses a)
telnet 38 (uses b)
I can't think of a case where splitting traffic this way is common
user desire. But as far as following rules go, that would be the
correct way to handle it.
2) And not be chained, with CIDR maps backing *.domain maps (uck,
because it's horrible breakage on expectation for tpo path).
map tpo a.exit
map 38 b.exit
telnet tpo (uses b)
telnet 38 (uses b)
3) Note today, there is also that IP automap backing thing in place:
map tpo a.exit
telnet tpo (uses a)
telnet 38 (uses a, via IP automap)
I'm guessing that was done for efficiency. If I drop in a further
(map 38 b), that seems to take precedence such that a future telnet
38 now uses b.
I don't have a problem with making the process of what I think
you're describing as 'BEGIN' hold just an IP... effectively using
Tor as a standard DNS cloud beforehand, then firing off the data
stream with BEGIN. CONNECTED would just be a 'ok, send more, no
need to find another circuit.'
It would normalize all the different ways IP and FQDN maps are
handled today (as above in 0, 1, 3).
The drawbacks I see (again, I'm lay) to that are:
1) Bad DNS exits are now possibly more frequently separate from the
traffic exit. So the stream events stuff would need to emit that
data to allow tracking bad DNS. That's not too bad. I think today
both DNS and traffic are forced over the same exit. Well, unless
maybe the exit dies halfway through or has no path?
2) Maybe a round trip slower to wait for explicit DNS? Given that
a request to *.53 may not wind up with the same router open (via
accept/reject) to *.port anyways... there's some average number of
circuit failures inherent in the current way, so maybe moving to
explicitly separate DNS and traffic stages, all client managed,
isn't that bad after all. And there might be some benefit to being
able to say, 'use only country code DNS exits, but let data go
wherever'.
Maybe it's some work, I don't know. Doesn't a pure DNS cell type
already exist (for resolving DNS forwarded via packet filters)?
I think the payoff for the (IP's present in HTML different than its
FQDN) and (map my entire VPN provider range to an exit in one rule)
type cases would be worth it.
I dont think there'd be any anonymity issues with this. Maybe a
little win if plaintext DNS doesn't appear so often anymore out the
same just before the traffic does.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3982#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs