On Thu, Mar 27, 2014 at 7:35 AM, Harry SeventyOne harry71@bk.ru wrote:

Hi,

I've written this (ugly, unconfigurable) patch for Tor which is designed to allow hidden services more information about their users, by giving each inbound circuit its own temporary "IP address" in the 127.x range. This technique works on Linux (I've not tried it on anything else) and allows the application server to do some useful things which were previously difficult:

• Identify TCP connections coming from the same client, in a short space of

time, for example, for diagnostic log analysis, identifying traffic trends

• Rate-limit operations coming from the same client, to defend against some

types of DoS attacks

• Temporarily block abusive clients (at least, until they make a new Tor

circuit)

More importantly, it can do this with an unmodified application-server (e.g. web servers typically have these features built-in) because it effectively "spoofs" the client ID as an ip-address, in the 127.x range.

The patch is currently not configurable (the feature can't be turned off). It only works with hidden services which are routed to "localhost".

Request for comments. What do you think?

Hi, Harry!

I like the idea of this feature, though really only the first application makes sense to me. (The other two seem like they'd just move DoS from one part of the protocol stack to another.) Are there other applications here, or ?

Quick notes:

* This needs to work for IPv6 too. - So, local_bind_addr should be tor_addr_t, not in_addr. - IPv6 would be better here, since it's easier to avoid collisions. - But to make this work for IPv6, we need to make it support ranges of addresses other than just localhost, since there is only one IPv6 address for localhost.

* As you noted, this needs to be configurable. - It should be configurable separately for separate hidden services.

* The new big blob of code in connection_exit_connect should really be moved to a new function, with unit tests.

* circuit IDs can collide trivially between connections, especially when they're only 16 bits wide. - Also, it makes me the tiniest bit nervous to expose a circuit ID as an identifier on two different links. It's probably not a problem if the app is correctly configured, but it would be better if the two weren't linkable.

* circuit IDs can get re-used, so the addresses here must not be used as any kind of identifier.

* This idea shares a lot of logic with the "virtual address" notion that address.c uses to implement AutomapHostsOnResolve and VirtualAddressNetwork/VIrtualAddressNetworkIPv6. Perhaps some of the code there could be adapted to get a little more abstract, so it could have separate map-on-demand objects for (address<->hostname) and (address<->circuit).

* It's better to do a patch like this against git master; Tor 0.2.4 is not going to get any new features.

And a process note:

* Patches that go to the mailing list sometimes get comments, but often get forgotten if they aren't merged fast. If you'd like to make sure this idea isn't forgotten, create a new ticket on trac.torproject.org.

many thanks,