[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Looking up bridges in Globe et al. by fingerprint
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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev