Patch: Hidden service: use inbound bind-address based on circuit ID (effectively giving each circuit a temporarily-unique IP address)
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? -- Harry SeventyOne
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, -- Nick
H Mon, 31 Mar 2014 12:38:01 -0400 от Nick Mathewson <nickm@alum.mit.edu>:
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 ? I'm not completely sure what applications exist. My experiments have shown that it's of some value in tracking clients, it certainly makes it easier to interpret web server access-logs.
The DoS angle only works against certain types of DoS, including perhaps some unintended DoS - such as robots or mirroring software which hits the server too fast, and needs to be rate-limited. I can see that a lot of work would probably be requires to make it work for the trunk of Tor, including the IPv6 work. I'm not completely sure whether I could do that. I wonder if there is a better proxy for the "client temporary identity" than circuit-id, and where we can get it from (in Tor's internal data-structure)? Circuit IDs certainly do get reused, but in my experience, not very quickly on low-traffic sites. This makes the logs make more sense, certainly to humans and possibly to log-analysis software.
* It's better to do a patch like this against git master; Tor 0.2.4 is not going to get any new features. But for users who want to try out the patch "right now", possibly on a production server, a patch against the stable release is more useful :)
Thanks for your helpful comments! Harry
participants (2)
-
Harry SeventyOne -
Nick Mathewson