[tor-dev] Looking up bridges in Globe et al. by fingerprint

[Christian]

On 09.02.2014 10:29, Karsten Loesing wrote:
> On 08/02/14 20:39, Roger Dingledine wrote:
> 
> Thanks for your reply.  This is very helpful!  Replying to your response
> inline and summarizing the design once again at the end of this email.
> 
>> On Mon, Feb 03, 2014 at 11:17:19AM +0100, Karsten Loesing wrote:
>>>   1. Globe runs full fingerprints through SHA-1 on the server.
>>>     - The Globe server learns a lot of bridge fingerprints, which
>>> makes it a juicy target, because bridge fingerprints can (in the
>>> future?) be used to fetch bridge descriptors containing bridge
>>> addresses.
>>>     + This variant is really easy to implement.
>>
>> This one sounds good to me. You could even check both the fingerprint
>> you get and its SHA1, so people who get the Javascript won't be sharing
>> their bridge fingerprint with you, and then this issue is limited to
>> the folks who don't want to run javascript.
> 
> Good idea, I guess that's doable.
> 
>> (I had no idea that Globe was doing this Javascript trick on the client
>> side, so I figured it was a straightforward security decision on my part,
>> "is it worthwhile to look up this bridge fingerprint, even though it
>> tells Globe about the fingerprint?" And I think that's a decision that
>> most people are able to make.)
> 
> Agreed.
> 
>> (Also, you say 'in the future?' above, but I think it can happen right
>> now -- if you ask Tonga about a bridge fingerprint, it will give you
>> the corresponding descriptor. Unless we disabled that on the Tonga side
>> when I wasn't looking.)
> 
> I said "(in the future?)" because I wasn't sure about this.  But I just
> looked a bit closer at the code and found that Tonga only sends out
> bridge descriptors over _encrypted_ connections, that is, requests
> coming in via Tor circuits.  That's why I never observed Tonga giving
> out a descriptor when asking it using curl or wget.  Makes sense now!
> 
>>>   2. Globe does not run full fingerprints through SHA-1 on the server
>>> and instead forwards everything to Onionoo.
>>>     - Not only the Globe server, but also the Onionoo server learns
>>> bridge fingerprints.
>>
>> Yeah, this doesn't seem like a good option.
> 
> OK.
> 
>>>     + We teach users that they shouldn't copy their original bridge
>>> fingerprint into the Globe search window.  For example, we could
>>> tell them the single line of Python they need to run their
>>> fingerprint through SHA-1.  While they might have "spoiled" their
>>> first bridge, they'll know for their other bridges.
>>>     - Nobody will understand the above.
>>
>> Well, I guess technically we could offer this too -- that way smart
>> users have the possibility to pre-SHA1 their fingerprint before doing
>> the search. And if Globe checks both, then it should just work either
>> way.
> 
> We can combine the idea of teaching users that they shouldn't tell us
> their original fingerprint with the idea above of hashing their
> fingerprint for them: whenever the Globe server sees a fingerprint, it
> hashes it and asks Onionoo for matches.  And if Onionoo returns a single
> bridge for exactly that hash, Globe knows that the fingerprint given by
> the user was not hashed and includes a warning.
> 
>> (Except, what if the users pre-SHA1 their fingerprint, but then
>> they run the javascript that SHA1's it again? Does that mean Globe should
>> check two hashes deep? Hrm.)
> 
> Globe doesn't have to check two hashes deep, but Onionoo already does
> that.  A common use case, AIUI, is that people search for their original
> fingerprint, see the bridge details page showing the fingerprint hash,
> copy that somewhere, and next time ask for the fingerprint hash.  And
> that has to return the same bridge already.
> 
>>>   3. Tor prints out the SHA-1 fingerprint to its logs or to a
>>> hashed-fingerprint file.
>>>     + Bridge users who know to read the fingerprint file can as well
>>> read the hashed-fingerprint file or the logs.  We could even add a
>>> link "How do I search for my bridge" to the Globe page and explain
>>> to look out for that file or read the logs.
>>>     - Only very few people will find that file or click the link.
>>> We'll have to do either 1 or 2 in addition to 3.
>>
>> I guess I don't object to this option, but I think you're right that
>> it isn't a big win.
> 
> Okay, let's consider it in the not-too-far-away future.
> 
>>>   4. Sanitized bridge descriptors contain original fingerprints.
>>>     + It will be a lot easier to search for bridges if it works the
>>> same way as searching for relays.
>>>     + The sanitizing process will be easier.
>>>     - We lose the option to enable bridge clients to update their
>>> bridge descriptors by sending the bridge fingerprint to the bridge
>>> authority.
>>>     - This is going to keep me busy for a while for updating the
>>> various metrics code that expects SHA-1 fingerprints rather than
>>> original fingerprints.  I can do that though.
>>
>> That doesn't sound like a good tradeoff either.
> 
> Agreed.  This suggestion seemed like a better idea when I thought that
> it was just planned that Tonga returns bridge descriptors when asked for
> fingerprints.  It doesn't make as much sense anymore.
> 
> 
> Summarizing the design:
> 
> 1. Globe browser
> 
> - If JavaScript is available, the browser-part of Globe computes the
> SHA-1 of any 40 hex chars given as input and sends that to the Globe
> server.  It uses a different parameter than the non-JavaScript version
> of Globe though, say, "search2=<str>", so that Globe server can
> distinguish.
> 
> - If JavaScript is not available, Globe browser simply sends the search
> paramter as "search=<str>" to the Globe server.
> 
> - There should be a link "how do I search for my bridge", or similar,
> that explains how to find their bridge's fingerprint and run it through
> SHA-1 before searching for it in Globe.
> 

If anyone wants to write a small text for this, feel free to do so.

> 2. Globe server
> 
> - If asked for "search2=<str>", the Globe server simply forwards the
> request to the Onionoo server.  Nothing to worry about here, Onionoo
> will handle the case of <hash> being a SHA-1 fingerprint (if the user
> put in their original fingerprint) or the SHA-1 of the SHA-1 fingerprint
> (if the user put in a fingerprint hash).
> 
> - If asked for "search=<str>", the Globe server performs the same check
> as the JavaScript Globe would have done.  If it detects 40 hex chars, it
> computes the SHA-1 and sends it to Onionooo.  Otherwise it simply
> forwards to Onionoo.  When Onionoo replies, Globe server checks if the
> response contains a single bridge with the hashed fingerprint being the
> SHA-1 that Globe server computed.  In this case the <str> part that it
> was given was a non-hashed fingerprint.  If so, Globe server includes a
> warning that users shouldn't put in their original fingerprint and
> suggests to use the fingerprint hash instead in the future.
> 
> 1.b Globe browser
> 
> - In fact, the JavaScript version of Globe browser could perform the
> same check as Globe server when receiving a response.  It could teach
> users not to put in their original fingerprint, because who knows, maybe
> next time they're searching using a non-JavaScript browser.  Also, they
> might wonder why the displayed fingerprint is different from what they
> typed in.
> 
> 3. Tor
> 
> - Once this whole fingerprint hash business is more common, because
> people are actually getting used to using their fingerprint hash in
> Globe, we discuss writing a hashed-fingerprint file and printing the
> hashed fingerprint to the logs on bridges.
> 
> Christian, does this make sense to you?  Shall we move these ideas to
> Trac tickets?
> 

Sounds good, but you don't need to create a ticket for this. I'm almost
done with this feature.

p.s. for testing the unhashed bridge fingerprint search I need to know
an unhashed bridge fingerprint. Does anyone knows where I can get one?

Thanks,
Christian