Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #8742

Closed (moved)
Open
Opened Apr 19, 2013 by Trac@tracbot

Byte history leaks information about local usage/hidden services

Not sure if this is related to #516 (moved).

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.

Trac:
Username: alphawolf

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#8742