Opened 8 years ago

Closed 17 months ago

#2668 closed defect (fixed)

Rate limit RELAY_EARLY and TLS by IP

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: tor-relay, tor-dos
Cc: Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor:

Description (last modified by mikeperry)

It is possible to execute an amplification attack on the Tor network and/or the directory authorities by launching many onionskin and tls attempts to each relay. These onion skins do not have to be valid, and can be replays: their only purpose would be to induce a relay to perform the PK step to attempt to decrypt them. Such an amplification attack can be used to consume all of the spare CPU of a relay.

One solution would be to rate limit RELAY_EARLY and TLS connections by IP address as opposed to by only circuit.

This ticket is meant as a place for the discussion for the creation of a proper Tor proposal for this behavior.

Child Tickets

Change History (26)

comment:1 Changed 8 years ago by mikeperry

Description: modified (diff)

comment:2 Changed 8 years ago by nickm

Rate-limiting TLS by IP is, I think, a good idea. One way to limit the attack multiplier here is to impose a slight delay between successful TLS connections from a single IP, and a larger delay between failed TLS connections. (It's relatively cheap to force the server to do a TLS handshake resulting in a failure, and relatively less cheap to force the server to do a TLS handshake resulting in a success.)

Rate-limiting CREATE cells is harder. If we get a bunch of circuits from some host x, it's not easy to tell if x is responsible, or if somebody is just using x as an intermediary. The same problem could apply to RELAY_EARLY cells: if x is sending a bunch of them, is x a client trying to use lots of CPU, or is x relaying them for someone else?

Another idea is that instead of rate-limiting early RELAY_EARLY cells and TLS handshakes we could prioritize in the way similar to what we do for circuit ewma: we could prioritize EARLY cells and TLS handshakes from addresses that haven't sent any in a while.

In addition to rate-limiting, we could/should also add proof-of-work features to future protocol versions. We'd want a consensus parameter to limit the maximum work factor, and we'd need a way to tell clients what kind of proof-of-work is needed. Of course, this won't help existing servers that need to support existing clients, since existing clients don't send proof-of-work.

comment:3 Changed 8 years ago by nickm

Milestone: Tor: unspecified

comment:4 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:5 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:6 Changed 4 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.7.x-final

Worth looking at during 0.2.7 triage IMO

comment:7 Changed 4 years ago by nickm

Status: newassigned

comment:8 Changed 4 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:9 Changed 4 years ago by isabela

Keywords: SponsorU added
Points: medium
Version: Tor: 0.2.7

comment:10 Changed 4 years ago by nickm

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

comment:11 Changed 4 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:12 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final
Status: assignednew

Turn most 0.2.8 "assigned" tickets with no owner into "new" tickets for 0.2.9. Disagree? Find somebody who can do it (maybe you?) and get them to take it on for 0.2.8. :)

comment:13 Changed 3 years ago by isabela

Sponsor: SponsorUSponsorU-can

comment:14 Changed 3 years ago by nickm

Keywords: tor-dos added

comment:15 Changed 3 years ago by isabela

Points: medium3

comment:16 Changed 3 years ago by nickm

Parent ID: #2664#17280

comment:17 Changed 3 years ago by nickm

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

comment:18 Changed 3 years ago by nickm

Sponsor: SponsorU-can

comment:19 Changed 3 years ago by nickm

Parent ID: #17280
Severity: Normal

comment:20 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:21 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:22 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:23 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:24 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:25 Changed 2 years ago by nickm

Keywords: 027-triaged-1-in removed

comment:26 Changed 17 months ago by dgoulet

Resolution: fixed
Status: newclosed

I think this also falls under #24902 which limits concurrent connection per client IP address. The detection takes place *after* the TLS negotiation since it is only at that point that we know if the client has to be considered a client or relay.

#24767 will also helps by not making relays DoS each other in case the TCP connection fails between relays.

Note: See TracTickets for help on using tickets.