[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