[tor-dev] Patch: Hidden service: use inbound bind-address based on circuit ID (effectively giving each circuit a temporarily-unique IP address)

[Nick Mathewson]

On Thu, Mar 27, 2014 at 7:35 AM, Harry SeventyOne <harry71 at 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