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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
