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

[Roger Dingledine <arma@xxxxxxx>]

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

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev