[tor-bugs] #9498 [Tor]: Allow bridge descriptors to contain no address if they are not being published

[Tor Bug Tracker & Wiki]

#9498: Allow bridge descriptors to contain no address if they are not being
published
-----------------------------+-------------------------------------------
     Reporter:  nwf          |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:  Tor: unspecified
   Resolution:               |   Keywords:  tor-bridge,need-spec,bridgedb
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-------------------------------------------

Comment (by nwf):

 Responding to various points raised:

 > If you do write a spec for this please be clearer about the reason for
 it.

 The intention here is to allow someone (i.e. me) who might otherwise run a
 Tor proxy and an "isolating proxy"-style setup to instead run an
 unpublished Tor bridge and expose its bridge port to the isolated node,
 which in turn runs a Tor proxy set to use that bridge.  The advantages
 here are
   * Bridging Tor rather than bringing the SOCKS proxy across the link
 allows running self-contained hidservs and gives the isolated node full
 control over its behavior within Tor.
   * The mechanism of exposure for the bridge port need not be an IP
 network -- a serial stream will do just fine.  This reduces the attack
 surface available to a would-be de-anonymizing adversary who has
 compromised the VM, but this reduction is only meaningful if the bridge
 doesn't announce its address to the isolated node, which is why I had it
 scrub the address information.  (Concretely, consider, for example, that
 by default Linux responds to ARP requests arriving on any interface for
 any address configured on any interface; a compromised user node in a
 typical "isolating proxy" setup would therefore be able to probe the
 network link between the end node and the Tor proxy, and, if the machine
 hosting the proxy has a public IP address, thereby de-anonymize the
 proxy's user.  This is just one example; UNIX IP stacks tend to be large
 and complex and I am doubtful that they could be made believably free of
 such information exposures.  The advantage of using something like a high-
 speed serial link is that the only attack surface available is the inside
 of the bridge port, the socat-like tool for bridging serial to TCP on the
 bridge, and the bridge's kernel's serial layer.  Unfortunately, this is
 currently immaterial due to #7144; a compromised proxy host in this setup
 easily reveals its bridges by making circuits through adversary-controlled
 2nd hops.)

 I recognize that this is something of an abuse of the intended
 functionality of bridges -- I'm trying to control the proxy's choice of
 first hops so that I can get a machine which can be said to be reasonably
 well connected to the Internet but that cannot discover any IP address
 information for said first hops (and has no non-127/8 address for itself).
 (Though again see #7144.)

 > It could potentially (though not currently, with this patch) allow
 clients who use bridges which are not contained in BridgeDB to verify the
 onion-key, signing-key, and fingerprint of their bridge.

 I am confused.  When I ran this experimentally, the Tor proxy had
 {{{
 Bridge 127.0.0.1:12345 0123456789ABCDEF0123456789ABCDEF01234567
 }}}
 in its config file; I thought the wad of hex there was the bridge's
 fingerprint and that the proxy's connection to the bridge and the bridge's
 proffered self-descriptor would be verified against it?

 > I am worried also that private bridges creating falsified descriptors
 will break things, since BridgeDB, [...]

 I'm not sure why BridgeDB is relevant here -- the descriptors are not
 intended to be published at all?

 Thanks!

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