Looking up bridges in Globe et al. by fingerprint
Hi bridge address distribution people, hi bridge status website developers, hi bridge operators, here's a problem that recently came up when Christian and I discussed making Globe a JavaScript-free website. The current Globe uses client-side JavaScript to detect if the user entered a 40-character hex fingerprint. In that case, it runs the input through SHA-1 and sends only the digest to the Onionoo service. That's why Onionoo supports four cases and does not support a fifth case (number 3 below): 1. original relay fingerprint: return the matching relay, because it might have been a different client than Globe that sent the request and did not run the fingerprint through SHA-1; 2. SHA-1 of relay fingerprint: return the matching relay, too, because this could have been Globe running the original relay fingerprint through SHA-1; 3. original bridge fingerprint: don't return anything, because Onionoo should not see original bridge fingerprints at all; 4. SHA-1 of bridge fingerprint: return the matching bridge, because not all clients are like Globe and might not run fingerprints through SHA-1; and 5. SHA-1 of SHA-1 of bridge fingerprint: return the matching bridge that the user was looking for when they put in the SHA-1 fingerprint which was then converted to the SHA-1 of the SHA-1. That's what the current Globe can do, because it uses JavaScript on the client side. But the new server-side Globe cannot do that! And I don't have a good solution yet. Here are some ideas, each of them having pros (-) and cons (+): 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. 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. + 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. 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. 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. What do you think? All the best, Karsten
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. (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.) (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.)
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.
+ 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. (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.)
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.
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. Thanks! --Roger
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. 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? All in all, we're reducing the problem that Globe learns lots of bridge fingerprints to Globe users that a) don't use JavaScript, b) don't read the "how to search for my bridge" link, *and* c) disregard the warning that they are not supposed to put in non-hashed fingerprints for their second on further bridges. Sounds like a good compromise. Again, thanks for your input here, Roger! All the best, Karsten
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
On Mon, Feb 10, 2014 at 10:09:10PM +0100, Christian wrote:
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.
We still like having tickets for things that are almost-done. That way you get the satisfaction of seeing it closed when you're done, and also there's a thing to point people to when we're talking about the thing you did.
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?
Mine is: bridge CA7434F14A898C7D3427B8295A7F83446BC7F496 You could also in theory get more from bridges.torproject.org, but that site sure is having some problems these days. --Roger
On 10/02/14 22:42, Roger Dingledine wrote:
On Mon, Feb 10, 2014 at 10:09:10PM +0100, Christian wrote:
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.
Exciting! Just in case I didn't say it before or not often enough: you're really doing a fantastic job with Globe, Christian! Thanks!
We still like having tickets for things that are almost-done. That way you get the satisfaction of seeing it closed when you're done, and also there's a thing to point people to when we're talking about the thing you did.
I just created #10882, #10883, and #10884 for this. All the best, Karsten
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?
Mine is: bridge CA7434F14A898C7D3427B8295A7F83446BC7F496
You could also in theory get more from bridges.torproject.org, but that site sure is having some problems these days.
--Roger
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (3)
-
Christian -
Karsten Loesing -
Roger Dingledine