Opened 5 years ago

Last modified 2 weeks ago

#8742 reopened defect

Byte history leaks information about local usage/hidden services

Reported by: alphawolf Owned by:
Priority: High Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Blocker Keywords: byte-history, stats, tor-hs, privacy, tor-relay, 026-triaged-1, 027-triaged-1-in, PostFreeze027
Cc: Actual Points:
Parent ID: Points: medium
Reviewer: Sponsor: SponsorR

Description

Not sure if this is related to #516.

When acting as a relay, Tor seems to collect and report on *all* incoming and outgoing bandwidth. This data is then published publicly on Atlas, torstatus, or available for download.

As an example, if you look at the monthly graph, it's pretty clear this relay become "something more than a relay" around the 7th of April:
https://atlas.torproject.org/#details/85617CE64344948B0BAC23CD4E22245F7F66C1C8

An attacker could use this data to determine if a relay hosts a hidden service (generally more bytes written than read), or if a user was actively browsing/downloading (more bytes read, generally) during a certain period of time. An active attacker could then create a large amount of traffic to a hidden service, perhaps creating a known pattern of high traffic followed by a period of little traffic, then review the byte history again and look for any relays that displayed a difference of read/write similar to the generated traffic. Having narrowed down the candidates, a DDOS of the relay would provide confirmation.  Exposing clients would of course be far more difficult, as most probably do not run as a relay.

Possible solutions:
*By default, don't count any traffic to/from a hidden service. Could be enabled optionally in torrc... if someone really wanted it.

*By default, don't count any traffic beginning at tor's socks port. I can't think of any reason someone would want to enable this... but if there is a good argument for it, perhaps provide an option in torrc for this too.

*Most drastically... let a user opt out of reporting byte history completely. I'm guessing this is a "no go", since the stats are needed to help better network performance.

Child Tickets

Attachments (1)

0001-Warn-if-Tor-is-a-relay-and-a-HS.patch (1.1 KB) - added by gsathya 4 years ago.
tor patch

Download all attachments as: .zip

Change History (21)

comment:1 Changed 5 years ago by nickm

Keywords: byte-history tor-hs tor-relay added; byte history hidden service removed
Milestone: Tor: unspecified

Directory caches also write more than they read.

comment:2 in reply to:  1 Changed 5 years ago by alphawolf

Replying to nickm:

Directory caches also write more than they read.

True... but in this case I happen to know that his particular relay has had a DirPort open for months, and began hosting a hidden service/relaying local network traffic around Apr-7. The divergence of read/write bytes is pretty obvious at that point. Prior to that date there is only a slight bias to more write traffic. Accepting that other directory caches might have a more pronounced bias, I still believe the attack I describe would be successful, as the attacker could create a divergence pattern that would be otherwise unlikely. It would of course require testing to confirm.

comment:3 Changed 5 years ago by nickm

Keywords: 024-backport added
Milestone: Tor: unspecifiedTor: 0.2.5.x-final
Priority: normalmajor

Marking as to-do for 0.2.5, with possible backport for 0.2.4 if it turns out not to be destabilizing.

comment:4 Changed 5 years ago by alphawolf

I'm not entirely sure why, but it looks like setting CountPrivateBandwidth might mitigate this issue. You can see on the 1 Week graph here:
https://atlas.torproject.org/#details/85617CE64344948B0BAC23CD4E22245F7F66C1C8

There is a period in the middle where the bytes written/read do not diverge, which corresponds with the time that CountPrivateBandwidth was set to 1. When the setting was removed, the written bytes began to exceed the read bytes again.

comment:5 Changed 4 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

comment:6 Changed 4 years ago by andrea

Keywords: 026-triaged-1 added; 024-backport removed

There's a complicated solution here:

1.) Keep track at the level of the number of bytes that go out as cells before the channel layer by cause (relay vs. local client vs. hidden service)
2.) Calculate proportions and apply them to the raw numbers that go over the wire so we only report the amortized number of bytes due to relay activity

This is probably too complicated to be worth it. We should deprecate this and warn in the log file if we're running a relay and a hidden service. Since this is easy, let's keep it in 0.2.6.

comment:7 Changed 4 years ago by gsathya

Status: newneeds_review

Changed 4 years ago by gsathya

tor patch

comment:8 Changed 3 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: unspecified
Status: needs_reviewnew

I've applied a tweaked version of gsathya's patch to master as a new ticket; see #12908.

I believe that doing this makes it ok to defer the rest of this ticket to "unspecified".

comment:9 Changed 3 years ago by cypherpunks

I've got the warning

Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742

while I'm running a hidden service and a bridge. Looks like a bug to me, since by bandwidth graphs are not public, thus not leaking anything useful.

comment:10 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.7.x-final

Worth looking at during 0.2.7 triage IMO

comment:11 Changed 3 years ago by nickm

Status: newassigned

comment:12 in reply to:  9 ; Changed 3 years ago by asn

Replying to cypherpunks:

I've got the warning

Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742

while I'm running a hidden service and a bridge. Looks like a bug to me, since by bandwidth graphs are not public, thus not leaking anything useful.

Bridge descriptors and extrainfos get published as well. There is a sanitization procedure which does not clean up the bandwidth info: https://collector.torproject.org/formats.html#bridge-descriptors

In any case, this warning message seems well placed. Maybe we should turn it into a REJECT or that's a bit too harsh? Maybe we should phrase it better if we can?

comment:13 Changed 3 years ago by nickm

Keywords: 027-triaged-1-in added

Marking some tickets as triaged-in for 0.2.7 based on early triage

comment:14 Changed 3 years ago by isabela

Keywords: SponsorR added
Points: medium
Version: Tor: 0.2.4.12-alphaTor: 0.2.7

comment:15 Changed 2 years ago by nickm

Keywords: PostFreeze027 added

If we wind up with a nice patch for any of these in the appropriate window, we should sure merge it.

comment:16 Changed 2 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

Not expected patches for these by Monday. :(

comment:17 Changed 2 years ago by nickm

Keywords: SponsorR removed
Sponsor: SponsorR

Bulk-replace SponsorR keyword with SponsorR sponsor field in Tor component.

comment:18 in reply to:  12 Changed 2 years ago by asn

Resolution: fixed
Status: assignedclosed

Replying to asn:

Replying to cypherpunks:

I've got the warning

Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742

while I'm running a hidden service and a bridge. Looks like a bug to me, since by bandwidth graphs are not public, thus not leaking anything useful.

Bridge descriptors and extrainfos get published as well. There is a sanitization procedure which does not clean up the bandwidth info: https://collector.torproject.org/formats.html#bridge-descriptors

In any case, this warning message seems well placed. Maybe we should turn it into a REJECT or that's a bit too harsh? Maybe we should phrase it better if we can?

I think this ticket can be closed based on the above message.

Please reopen if you disagree.

comment:19 Changed 2 weeks ago by 43901348

Severity: Blocker

PLEASE reopen this. Having "fixed" the issue by only adding a startup warning is inaccurate and insufficient:

  • Some admins will never see the warning
  • Some admins will see the warning, come to this link, see the issue is fixed and conclude the warning is out of date
  • The list of proposed solutions in the issue summary does not include "just add a startup warning, but don't address the issue itself"

This can easily lead to misunderstandings. Please keep the issue open, or if you don't think it's worth fixing, please then mark it as WONTFIX.

Anything but what you have now would be a good start, but a more robust solution would be to ensure that administrators see this warning, and ideally have to acknowledge that they know what they are doing by setting a configuration switch in torrc to allow a relay and HS to be run in the same instance.

As it stands now, you are putting some administrators at risk of unnecessary HS discovery.

Last edited 2 weeks ago by 43901348 (previous) (diff)

comment:20 Changed 2 weeks ago by 43901348

Resolution: fixed
Status: closedreopened

I guess I am allowed to re-open it. Please adjust as necessary, including closed as WONTFIX if that's really the consensus.

Note: See TracTickets for help on using tickets.