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

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev