[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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:               |
-----------------------------+-------------------------------------------
Changes (by isis):

 * cc: isis@â (added)
 * keywords:  tor-bridge => tor-bridge,need-spec,bridgedb


Comment:

 Adding keyword 'need-spec'.

 This is a really neat idea. 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. Although to do that, there ought to be some
 sort of challenge-response between the client and the bridge, i.e.
 something like:

  1) client connects to bridge and asks it to sign a nonce.
  2) bridge signs and sends it back.
  3) client checks that the signature was made with the key received from
 the bridge-server-descriptor, and that both sigs are valid.

 I am worried also that private bridges creating falsified descriptors will
 break things, since BridgeDB, as well as anything else which parses
 descriptors looking for addresses -- such as (probably) metrics-tasks,
 stem, and arm, would need to be changed to understand this.

 Also, there is much more identifying information in the bridge-server-
 descriptors than just the IP. I see the following problems:

   * Would such a bridge report its extrainfo descriptor? Because the
 {{{@type bridge-extrainfo}}} contains {{{read-history}}} and {{{write-
 history}}} lines, which, if a bridge has very few users, could possibly
 damage those user's anonymity. For example, if a bridge had only one user
 (which could be quite likely, since it is a private bridge), anyone who
 had this information could possibly determine some information about the
 browsing habits of the user (though likely no more than sitting outside
 the user's house in a black van and wiretapping everything).
   * The {{{@type bridge-server-descriptor}}} contains the {{{contact}}}
 line which is likely also problematic.
   * The {{{@type bridge-extrainfo}}} contains also the {{{geoip-client-
 origins}}} / {{{bridge-ips}}}, these might be problematic. Also, the
 {{{transport}}} line, if it has one.

 Currently, a bridge descriptor ({{{@type bridge-server-descriptor}}})
 looks like this:
 {{{
 @purpose bridge
 router thisisafakebridge 11.11.11.11 9001 0 0
 platform Tor 0.2.3.25 on Linux
 opt protocols Link 1 2 Circuit 1
 published 2013-08-21 12:00:00
 opt fingerprint 26E5 B0C0 0C5D F12A 3C96 9D35 BA71 4527 8AEC 2B96
 uptime 2171396
 bandwidth 5243880 10585760 160875
 opt extra-info-digest D34DB33FD1511CDDAF9486D8615CCBD48E1C07F8001
 onion-key
 -----BEGIN RSA PUBLIC KEY-----
 MIGJ3oGBAJMrq17ZyIxZBAVwbQXUiY2ZpzNj/fLINjo4snw75wx+sex6iwM+kYsr
 JMyGOU1oFDUpz6dHXmk/tZw0F46B7TV4Ae+f6iEkRLWNuxah2Jvr8wci55ZAJWV9
 rVR1sHndj4y3CJeCqYjPxmWUJSxO9evPKjjOZbmbyeJox7alRUkTAgMBAAE=
 -----END RSA PUBLIC KEY-----
 signing-key
 -----BEGIN RSA PUBLIC KEY-----
 MIGJAoGBALhRvLOjvM2pUSA6Njq29rq23rawYIsk6fvWo9mwucSCQrw75whCMzj8
 VVWbrpvxkT1bxxEpwuxeawef98u323rqg4ffpsL7riUcKlL4GAG7QhOKVdqCx6FJ
 svvHOUKCAHTxsqjit2/LzPhQ/DuUxFn9awef8mEUgBs0tIdnaowe24LMBAAE=
 -----END RSA PUBLIC KEY-----
 opt hidden-service-dir
 contact SoAndSo <soandso@xxxxxxxxxxx>
 ntor-onion-key AYZTRGjUdo+VuurT3VkgNzPWuUf/LT4VCq78wMwlWio=
 reject *:*
 router-signature
 -----BEGIN SIGNATURE-----
 PAUsG3Pcz7X39bE8NlCmBBoCOEPQwNhNO52IebNUqnh7gfyoq3dqGqHMIC0PJ5WJ
 SW6P6LAqpi0MopIl8D8YxcD69xWO/0mTBZDaZT3EOEBW2PcYinNg4vwOCj/kxpaM
 Zbl3BpbnudVGzASc7UgxQcjWBtXVOiI44FdX3RtG7tM=
 -----END SIGNATURE-----
 }}}

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9498#comment:3>
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