Opened 8 years ago

Closed 3 years ago

#6470 closed enhancement (wontfix)

distinguishing between (non-) hidden service hosters, too few/much open circuits

Reported by: proper Owned by: arma
Priority: Medium Milestone:
Component: Metrics/Analysis Version:
Severity: Keywords:
Cc: proper, special, phw, yawning, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


For Internet Service Providers it's too easy to find who hosts a hidden service and who doesn't.

For people connecting to the public Tor network:

  • Tor users have X open circuits after Tor started.
  • Hosters of hidden services have much more open circuits after Tor started. In my tests it were mostly X*3 open circuits.
  • It's trivial for ISPs to distinguish between non-hidden-services and regular Tor users.
  • That analysis combined with another attack, such as Murdoch's clock skew attack can de-anonymize Tor hidden service hosters.

For people connecting to (obfuscated) bridges:

  • Same as above but depends on the ability of the ISP to detect connections to the Tor network.

Suggested solution:

  • Open the same amount of circuits. Do not let that depend on if the user hosts a hidden service or not.

Child Tickets

Change History (11)

comment:1 Changed 8 years ago by karsten

Component: AnalysisTor Client
Type: taskenhancement

Not an analysis ticket. Also sounds like a FAQ.

comment:2 Changed 8 years ago by proper

Analysis as in "needs research". Open questions for research:

  1. "Is it true that Tor opens much more circuits when a hidden service port gets activated?" I think I can't be wrong here.
  1. Would it circumvent this attack if users who don't have a hidden service ports build the same amount of circuits like people who use a hidden service port?
  1. Would it circumvent this attack if every Tor user had a hidden service port activated? (pointing to nothing by default)

comment:3 Changed 8 years ago by ioerror

I've just talked about this with Roger at PETS - I agree that this is a problem and I agree that we should be at least trivially non-distinguishable.

comment:4 Changed 8 years ago by proper

What is required now? Research? Proposal? Implementation?

What's the right component and assignee?

comment:5 Changed 8 years ago by proper

Component: Tor ClientAnalysis
Owner: set to arma
Status: newassigned

Giving this trustfully into Roger's hands to decide to encourage research, to delay this, to let this rot in trac or to close the ticket.

comment:6 Changed 5 years ago by arma

It would be neat to learn how much overhead (in number of timing of circuits) it would take to get the two scenarios closer together.

I currently think it is not practical to make the two scenarios indistinguishable in practice. But maybe it is feasible to do it in the case where the hidden service receives no requests?

Step one is indeed research -- to answer the above questions.

comment:7 Changed 5 years ago by special

Cc: special added

comment:8 Changed 5 years ago by phw

Cc: phw added

Even if the amount of circuits would be identical, we would still have to worry about other identifiers such as the bytes transferred. Assuming HTTP, onion services tend to send more bytes than they receive, whereas Tor users tend to receive more bytes than they send.

comment:9 Changed 5 years ago by yawning

Cc: yawning added

comment:10 Changed 5 years ago by teor

Cc: teor added

comment:11 Changed 3 years ago by karsten

Resolution: wontfix
Status: assignedclosed

Closing tickets in Metrics/Analysis that have been created 5+ years ago and not seen progress recently, except for the ones that "nickm-cares" about.

Note: See TracTickets for help on using tickets.