Opened 16 months ago

Last modified 4 weeks ago

#25066 new enhancement

Rendezvous points should return signed proof of the established rend point

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points:
Parent ID: #15516 Points: 15
Reviewer: Sponsor: Sponsor27-can

Description

Right now our protocol has a vulnerability where you can send an introduce attempt without actually establishing the rendezvous point that you send the onion service toward.

If the establish_rendezvous attempt sent back a signed acknowledgment from the relay, then you could include that signed acknowledgment in your introduce attempt, and the onion service could use it to decide whether to answer.

In the short term, when most people aren't including it, onion services would want to answer even when it's missing. But under load, or in the future where most people should be sending them, onion services could opt to discard introduction attempts that are missing a proof-of-rendezvous-point (or that provide a proof from a relay that the onion service doesn't know about).

This idea needs some crypto design where we want to choose a compact efficient-to-compute thing that the relay can return. And also we want to figure out which key should be signing it. And we probably want some sort of timestamp in the blob so onion services can discard really old ones.

Note that there's some flexibility for how we accomplish this goal, for example, if it helps we could change things so the relay tells the client what rendezvous cookie it can use.

(When I say efficient, I'll note that my relay right now is receiving about 160 establish-rendezvous attempts per second, sustained -- and that's after discarding the ones from tor2web clients.)

I am also open to other smart ideas on how best to resolve the protocol flaw. :)

Child Tickets

Change History (6)

comment:1 Changed 16 months ago by nickm

If we were to do this, we'd also have to make sure that these tokens are non-replayable... and possibly bound to a single onion service?

To be clear, this issue is "just" a DoS multiplier, right? At the cost of building a circuit and sending an introduce cell, the attacker causes the onion service to build another circuit?

comment:2 Changed 14 months ago by nickm

Keywords: 034-triage-20180328 added

comment:3 Changed 14 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:4 Changed 14 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:5 Changed 4 weeks ago by asn

Parent ID: #15516
Sponsor: Sponsor27-can

comment:6 Changed 4 weeks ago by asn

Points: 15
Note: See TracTickets for help on using tickets.