Opened 7 years ago

Closed 7 years ago

#8028 closed defect (fixed)

Decide how to sanitize ntor-onion-key lines in bridge descriptors

Reported by: torvlnt33r Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/CollecTor Version: Tor: 0.2.4.9-alpha
Severity: Keywords:
Cc: nickm, atagar, iang Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Since upgrading to Tor 0.2.4.9-alpha, my bridges do not appear with correct information in https://onionoo.torproject.org/details?type=bridge:

  • platform is either not present or still appears as "Tor 0.2.4.7-alpha on Linux". Note that, globally, no bridge is reported as running version 0.2.4.9, which is quite unlikely.
  • advertised_bandwidth is either not present or 0,
  • last_restarted is either not present or still the previous time from when previous version 0.2.4.7 was last restarted.

When downgrading to 0.2.4.7 (thanks to Debian snapshot), advertised_bandwidth moves away from 0, last_restarted and platform are correct again.

Child Tickets

Change History (6)

comment:1 Changed 7 years ago by karsten

Can you paste a hashed_fingerprint line of one of your bridges from Onionoo's output file here, so that I can look up the (sanitized) descriptors that your bridge published? (That hashed fingerprint can't be used to locate or use your bridge, so pasting it here won't make your bridge publicly known.)

comment:2 Changed 7 years ago by torvlnt33r

Yes. See for example: "hashed_fingerprint":"804FA2C6E8A1D0F7D19CA6ACDDFDF5EEE77848FA"

comment:3 Changed 7 years ago by karsten

Cc: nickm atagar added
Component: TorMetrics Data Processor
Owner: set to karsten
Status: newaccepted
Summary: Partial report for bridges running 0.2.4.9 in OnionooDecide how to sanitize ntor-onion-key lines in bridge descriptors

Found the problem. Your bridge includes an "ntor-onion-key (scrubbed)=" line in its descriptors, which the bridge descriptor sanitizer doesn't know, so it skips those server descriptors entirely. That's meant as safe default, so that we don't include anything new and potentially privacy-sensitive in the descriptors we make public. So, this part worked fine. (The part that didn't work so well is notifying us about skipped service descriptors, but that's a different problem.)

Before I can fix this, we'll have to discuss how to handle "ntor-onion-key (scrubbed)=" lines in sanitized bridge descriptors. Options are: a) remove those lines entirely, b) only keep the "ntor-onion-key" part and drop the "(scrubbed)" part, c) replace the key part with AAAAAA (or whatever is all zeroes in base64), d) keep the entire line because it's safe to do so. I can't answer this myself. The question is whether this key can be used in any way to locate the bridge. I assume not, but I'd want to be sure. Nick, Damian, thoughts?

torvlnt33r, thanks for reporting this problem! Please note that it may take a few days to discuss the changes and deploy the fix. I "stole" this ticket for this discussion, but I'll let you know once Onionoo should work correctly again. Thanks!

comment:4 Changed 7 years ago by karsten

Cc: iang added

nickm, iang, can you say whether it's safe to publish a bridge's unsanitized ntor-onion-key line? Or can such a line be used in any way to locate a bridge? I assume not, but I'd appreciate a confirmation. Thanks!

comment:5 Changed 7 years ago by iang

It seems safe to me. It's just a random group element.

comment:6 in reply to:  5 Changed 7 years ago by karsten

Resolution: fixed
Status: acceptedclosed

Replying to iang:

It seems safe to me. It's just a random group element.

Great, thanks!

metrics-db now leaves ntor-onion-key lines in sanitized bridge descriptors, missing sanitized bridge descriptors from January have been processed and will be included in tarballs in three days, and Onionoo should now show the correct information again.

Closing. Please reopen if something's still not working.

Note: See TracTickets for help on using tickets.