Opened 8 years ago

Closed 8 years ago

#5368 closed enhancement (implemented)

Accept hashed relay fingerprints and hashed hashed bridge fingerprints in search and lookup URLS

Reported by: karsten Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Onionoo Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

While thinking about how Atlas could add bridge search support, I came up with the following problem in the 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.

Child Tickets

Change History (1)

comment:1 Changed 8 years ago by karsten

Resolution: implemented
Status: newclosed

Implemented in b326055. Closing.

Note: See TracTickets for help on using tickets.