[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #5368 [Onionoo]: Accept hashed relay fingerprints and hashed hashed bridge fingerprints in search and lookup URLS
#5368: Accept hashed relay fingerprints and hashed hashed bridge fingerprints in
search and lookup URLS
-------------------------+--------------------------------------------------
Reporter: karsten | Owner: karsten
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Onionoo | Version:
Keywords: | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
While thinking about how Atlas could
[https://github.com/hellais/TorStatus/issues/8 add bridge search support],
I came up with the following problem in the
[http://onionoo.torproject.org/ Onionoo protocol].
Both the */lookup/ and */search/ URLs currently require a non-hashed
fingerprint to look up a relay and a hashed fingerprint to look up a
bridge. This works fine if a) users know how to hash fingerprints and b)
the client knows whether the user provided a hashed or non-hashed
fingerprint. But what if either a) or b) is not the case? If the client
sees a 40-character fingerprint it shouldn't simply submit it to the
Onionoo server. It might be a non-hashed bridge fingerprint.
The suggested change is to make */lookup/ and */search/ URLs accept hashed
relay fingerprints and hashed hashed bridge fingerprints. Clients would
then be advised to always hash any 40-character hex input they receive
from users and include that in their request to the Onionoo server. If
the user provided a non-hashed fingerprint of a bridge the client wouldn't
reveal the non-hashed fingerprint in the URL. If the user provided a
hashed fingerprint, looking up the hash of the hash would still work and
return the bridge the user was looking for.
The following text would be added to the protocol description:
"GET */search/:searchtext [...] Full fingerprints should always be hashed
using SHA-1, regardless of searching for a relay or bridge, in order to
not accidentally leak non-hashed bridge fingerprints in the URL."
"GET */lookup/:fingerprint [...] Fingerprints should always be hashed
using SHA-1, regardless of looking up a relay or bridge, in order to not
accidentally leak non-hashed bridge fingerprints in the URL."
This ticket doesn't solve the problem when the user provides only the
first, say, 9 to 39 hex characters of a relay or bridge fingerprint. The
client can only hash a full 40-character fingerprint, so there's no way
how the client can protect the user from herself here. But I think the
most common cases are that users type in the first, say, 8 characters of a
fingerprint or paste the full 40-character fingerprint. The first 8
characters alone don't reveal too much information, and the pasted
40-character fingerprints will be protected by the change suggested in
this ticket.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5368>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs