Opened 20 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: 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 (12)

comment:1 Changed 20 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 18 months ago by nickm

Keywords: 034-triage-20180328 added

comment:3 Changed 18 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 18 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 5 months ago by asn

Parent ID: #15516
Sponsor: Sponsor27-can

comment:6 Changed 5 months ago by asn

Points: 15

comment:7 Changed 3 months ago by cypherbits

I think this a bug on the original design that should have been addressed on the onion service v3 proposal and implementation.

Before making anything new to prevent DoS like proposal 305 we should have implemented this... because it is a defect on the original design. This, itself, will make DoS harder.

I hope version 0.4.3 can implement it.

comment:8 Changed 3 months ago by asn

The first step here is writing a proposal of how exactly this will work and posting it on tor-dev. AFAIK no one is working on this ticket atm.

comment:9 Changed 3 months ago by dgoulet

Parent ID: #15516#29999

Re-parenting properly.

comment:10 Changed 3 months ago by arma

To set expectations here: I think adding a proof-of-rendezvous-point to the design is a wild and crazy idea. It would be great to have a simpler and cleaner idea that helps solve the problem instead.

(And to respond to cypherbits's point, yes it can potentially help with future DoS issues, but we should also remember that it would not help with the current DoS issues, because as far as I know they really are establishing rendezvous points and otherwise following the protocol.)

comment:11 in reply to:  10 Changed 2 months ago by cypherbits

Replying to arma:

To set expectations here: I think adding a proof-of-rendezvous-point to the design is a wild and crazy idea. It would be great to have a simpler and cleaner idea that helps solve the problem instead.

The goal is to check the client actually established the rend point circuit... the only idea I have in mind is that the rend point signs the cookie. It should not be that expensive.
Now, that would be if it is the Hidden Service verifying the signature, but, what if we want it to be the Intro Point? Where to do the verify process?

I will make a proposal but before that I will have to analyze everything I can to choose where.

(And to respond to cypherbits's point, yes it can potentially help with future DoS issues, but we should also remember that it would not help with the current DoS issues, because as far as I know they really are establishing rendezvous points and otherwise following the protocol.)

comment:12 Changed 4 weeks ago by asn

Parent ID: #29999
Note: See TracTickets for help on using tickets.