[tor-bugs] #5368 [Onionoo]: Accept hashed relay fingerprints and hashed hashed bridge fingerprints in search and lookup URLS

[Tor Bug Tracker & Wiki]

#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