Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#26620 closed enhancement (fixed)

Tor Relay Guide: relays operators shouldn't expose their fine-grained monitoring graphs public

Reported by: ggus Owned by: Nusenu
Priority: Medium Milestone:
Component: Community/Relays Version:
Severity: Normal Keywords:
Cc: nusenu Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Even with this warning[1] in Tor Relay Guide, many operators still make their graphs public. We should make this warning bigger like #GettingHelp.

[1]"Note: Do not make your munin (or any other fine-grained monitoring) graphs public since this could help attackers with deanonymizing Tor users."

Child Tickets

Change History (20)

comment:1 Changed 2 years ago by cypherpunks

please provide examples or be more detailed in your description (e.g. do you mean real time monitoring data or screenshots of them)

comment:2 in reply to:  1 Changed 2 years ago by teor

Replying to cypherpunks:

please provide examples or be more detailed in your description (e.g. do you mean real time monitoring data or screenshots of them)

Real-time monitoring data, real-time graphs, and screenshots of detailed historical data are all bad for user privacy.

In more detail:

  • Currently, public bandwidth reporting over any period less than 24 hours provides less security than tor bandwidth statistics.
  • Reporting individual relays is worse than reporting totals for groups of relays. In future, we will securely aggregate Tor's bandwidth statistics, so any individual relay bandwidth reporting will be less secure than Tor's statistics.
  • Smaller periods are worse.
  • Numbers are worse than graphs.
  • Real-time data is worse than historical data.
  • Data in categories (IP version, in/out, etc.) is worse than total data.

If they want to report bandwidth, operators should aggregate all their relays' bandwidths over at least a week, then round to the nearest 10 terabytes.

comment:3 Changed 2 years ago by cypherpunks

we plan to publish
vnstati -m
output (monthly granularity), for servers (some servers run multiple tor instances, some only single)
and it has XX.XX TiB granularity, let me know if you want to discourage that

comment:4 in reply to:  3 Changed 2 years ago by teor

Replying to cypherpunks:

we plan to publish
vnstati -m
output (monthly granularity), for servers (some servers run multiple tor instances, some only single)
and it has XX.XX TiB granularity, let me know if you want to discourage that

Please round to the nearest 10 terabytes. If you report to the nearest 0.01 terabytes, that's 10 gigabytes per month, or 333 megabytes per day, which seems like a reasonable amount of usage for a client (and therefore something we should try to protect). Rounding to 10 terabytes is ok, because we can't protect clients that use 33.3 gigabytes per day. There aren't enough clients that use that much data.

Please report totals across multiple machines if you can, particularly for machines with only a single relay.

comment:5 Changed 2 years ago by cypherpunks

vnstati does not support rounding.

tor reports values daily (xx.xx MiB) for each tor instance.

You are basically saying 'reporting with significantly less granularity than tor itself is still NOT good'? (a single monthly value)

Last edited 2 years ago by cypherpunks (previous) (diff)

comment:7 in reply to:  5 ; Changed 2 years ago by teor

Replying to cypherpunks:

vnstati does not support rounding.

You could use your favourite scripting language to round the numbers.

tor reports values daily (xx.xx MiB) for each tor instance.

Tor reports values in its logs. Occasionally operators will paste logs onto tickets. But that's not the same as reporting them publicly every month.

You are basically saying 'reporting with significantly less granularity than tor itself is still NOT good'? (a single monthly value)

Yes, we're moving towards relay statistics that are securely aggregated across the network, with no individual relay totals.

Please do your best to protect Tor users by aggregating and rounding your bandwidth as much as you can.

comment:8 in reply to:  6 ; Changed 2 years ago by teor

comment:9 in reply to:  8 ; Changed 2 years ago by teor

Replying to teor:

Replying to cypherpunks:

https://twitter.com/coldhakca/status/891806775430742019

I'll talk to them.

That tweet is a year old. They stopped because of user privacy issues.

comment:10 in reply to:  7 ; Changed 2 years ago by cypherpunks

tor reports values daily (xx.xx MiB) for each tor instance.

Tor reports values in its logs. Occasionally operators will paste logs onto tickets. But that's not the same as reporting them publicly every month.

Tor does report data to dir auths and collector and onionoo publish it, RS makes graphs of it having daily granularity.

comment:11 in reply to:  9 ; Changed 2 years ago by cypherpunks

That tweet is a year old. They stopped because of user privacy issues.

I was well aware of it but it is prominently pinned and it animates others to basically do the same - and it is associated with the official torproject relay advocate.

comment:12 in reply to:  11 Changed 2 years ago by teor

Replying to cypherpunks:

That tweet is a year old. They stopped because of user privacy issues.

I was well aware of it but it is prominently pinned and it animates others to basically do the same - and it is associated with the official torproject relay advocate.

https://twitter.com/coldhakca/status/1014058685667135493

comment:13 in reply to:  10 Changed 2 years ago by teor

Replying to cypherpunks:

tor reports values daily (xx.xx MiB) for each tor instance.

Tor reports values in its logs. Occasionally operators will paste logs onto tickets. But that's not the same as reporting them publicly every month.

Tor does report data to dir auths and collector and onionoo publish it, RS makes graphs of it having daily granularity.

Yes, it does. And we're working on making it more secure. Please work with us to make it more secure.

comment:14 Changed 2 years ago by cypherpunks

could you put in references to the tickets? thanks!

comment:15 Changed 2 years ago by cypherpunks

since vnstat reports interface traffic and not tor-exclusive traffic I assume it is ok to publish, if it isn't please say so

comment:17 in reply to:  15 Changed 2 years ago by teor

Replying to cypherpunks:

since vnstat reports interface traffic and not tor-exclusive traffic I assume it is ok to publish, if it isn't please say so

I think you might have missed my earlier answer:

Replying to teor:

Replying to cypherpunks:

we plan to publish
vnstati -m
output (monthly granularity), for servers (some servers run multiple tor instances, some only single)
and it has XX.XX TiB granularity, let me know if you want to discourage that

Please round to the nearest 10 terabytes. If you report to the nearest 0.01 terabytes, that's 10 gigabytes per month, or 333 megabytes per day, which seems like a reasonable amount of usage for a client (and therefore something we should try to protect). Rounding to 10 terabytes is ok, because we can't protect clients that use 33.3 gigabytes per day. There aren't enough clients that use that much data.

Please report totals across multiple machines if you can, particularly for machines with only a single relay.

comment:18 Changed 2 years ago by cypherpunks

if weekly values should be rounded to the nearest 10TiB, should monthly values be rounded to the nearest 40 TiB?

Last edited 2 years ago by cypherpunks (previous) (diff)

comment:19 Changed 2 years ago by nusenu

Resolution: fixed
Status: newclosed

content from teor added to the guide:
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide?sfp_email=&sfph_mail=&action=diff&version=224&old_version=221&sfp_email=&sfph_mail=

a better graphic warning will be added once this guide is moved to the new portal.

if you are not happy with it, please do reopen this ticket

comment:20 in reply to:  18 Changed 2 years ago by teor

Replying to cypherpunks:

if weekly values should be rounded to the nearest 10TiB, should monthly values be rounded to the nearest 40 TiB?

I said that monthly values should be rounded to 10 TB:
https://trac.torproject.org/projects/tor/ticket/26620?replyto=18#comment:4

Weekly values should also be rounded to 10 TB, because it's a shorter period, and shorter periods are more risky for client anonymity.

(When we implement #22898, we will have a precise specification for the amount of noise that Tor adds. Then we can calculate the noise that he entire Tor network needs to add to keep bandwidth safe, and update the suggested rounding. I'm using 10 TB as a conservative estimate.)

Note: See TracTickets for help on using tickets.