[tor-project] Tor's history of D/DoS attacks; strategy for mitigation

Mailing Lists tor-project
1

I'm investigating the applicability of the IETF's DDoS Open Threat
Signaling (DOTS) specifications[1] to the needs of privacy-preserving
overlay networks, including VPNs but with particular interest in Tor.

Specifically, now that the July 2022 D/DoS attack has finally come to a
close, I'm wondering about:

1. the history, frequency, and magnitude of D/DoS attacks against the
   Tor network;

2. when these have taken the form of Tor traffic versus lower-level
   attacks on Tor nodes and HSDirs; and

3. how the new "proof of work over introduction circuits" scheme fits
   into Tor's overall strategy for mitigating D/DoS attacks.

I've found plenty of current and historical GitLab tickets---but I'm
wondering if there are more comprehensive documents or other resources
I'm not aware of.

  --- cfm[2].

[1]: DDoS Open Threat Signaling (dots)

[2]: I'm a maintainer of the SecureDrop project at the Freedom of the
     Press Foundation, but this work is supported by ARTICLE 19's
     Internet of Rights Fellowship.

2

I'm investigating the applicability of the IETF's DDoS Open Threat
Signaling (DOTS) specifications[1] to the needs of privacy-preserving
overlay networks, including VPNs but with particular interest in Tor.

Specifically, now that the July 2022 D/DoS attack has finally come to a
close, I'm wondering about:

1. the history, frequency, and magnitude of D/DoS attacks against the
    Tor network;

We have seen high volumes of onion service activity indicative of internal onion service DDoS roughly once a year for the past several years.

We also have seen periodic attacks against the directory authorities, going back several years.

2. when these have taken the form of Tor traffic versus lower-level
    attacks on Tor nodes and HSDirs; and

The most common attack has been either onion service related, or against the directory authorities. However, over the past year, we saw several attack attempts that appeared to target specific relays. This was a new phenomenon, at this scale.

We also saw some evidence of DDoS attack attempts through Tor. Relay operators have developed tools to block connections to external IP addresses that see connection spikes. One such example tool is: GitHub - artikel10/surgeprotector: Block Tor Exit traffic to flooded IP addresses via ExitPolicy.

We have made several attempts to secure funding to develop mechanisms to rate limit scraping, spam, and externally-destined DDoS attack activity happening through Tor, but so far, these funding proposals have all been rejected.

3. how the new "proof of work over introduction circuits" scheme fits
    into Tor's overall strategy for mitigating D/DoS attacks.

Around when the proof of work branch got finalized, the onion service attacks ended. We are not sure if this is related to the ability to deploy the PoW branch ad-hoc, or if it was just a coincidence.

Since the majority of DDoS activity has been onion service related, we expect this defense to act as a deterrent there, for most of the issues we have seen.

I've found plenty of current and historical GitLab tickets---but I'm
wondering if there are more comprehensive documents or other resources
I'm not aware of.

No. Many of the non-onion attacks we have noticed have confidential tickets. Many attacks were quite effective at degrading service, and appeared to have this as their goal. They were also appeared to be probing in nature, and often stopped after a few days or a week from starting. These attacks ran parallel to the larger onion service DDoS.

We recently obtained funding to fix these kinds of specific attacks against Guards, dirauths, and Exits, but many issues will remain confidential until we do so. We do not want to advertise which of these probing attacks were actually effective vs not, or why.

--- cfm[2].

···

On 6/26/23 04:10, Cory Francis Myers wrote:

[1]: DDoS Open Threat Signaling (dots)

[2]: I'm a maintainer of the SecureDrop project at the Freedom of the
      Press Foundation, but this work is supported by ARTICLE 19's
      Internet of Rights Fellowship.
_______________________________________________
tor-project mailing list
tor-project@lists.torproject.org
tor-project Info Page

--
Mike Perry
_______________________________________________
tor-project mailing list
tor-project@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

3

The most common attack has been either onion service related, or
against the directory authorities. However, over the past year, we saw
several attack attempts that appeared to target specific relays. This
was a new phenomenon, at this scale.

[…]

Since the majority of DDoS activity has been onion service related, we
expect [the proof-of-work] defense to act as a deterrent there, for
most
of the issues we have seen.

[…]

We recently obtained funding to fix these kinds of specific attacks
against Guards, dirauths, and Exits, but many issues will remain
confidential until we do so. We do not want to advertise which of
these probing attacks were actually effective vs not, or why.

Thanks very much for this summary, Mike. It sounds like there is a
clear division between (a) attacks targeting onion services, to be
mitigated by the proof-of-work defense; and (b) attacks with a clearnet
source or target, to be mitigated by this new work in progress.

I would separate the two parts of (b). Each will have different solutions, from our point of view.

Addressing attacks coming from Tor exits remains unfunded.

Addressing attacks against Tor relays is funded.

Most the probing attacks against relays that we saw probed for resource exhaustion conditions, which we will address via those conditions themselves. We did get a report of at least one instance of the typical UDP reflection flood against a Tor relay, though. It was quite large, but we only heard this report from one relay operator (and there are several thousand relay operators).

For the latter, could there be value in a mechanism that allows nodes
(especially relays) to coordinate either local or upstream blocking of
traffic from D/DoS sources? This is the potential application I’m
investigating of the IETF DOTS standard. But it may be an approach
you’ve either already selected or ruled out.

"It depends".

It is unlikely for us to get directly involved in IP address blacklist or IP address reputation games. Tor user experience is significantly degraded by these systems. While we are trying to pitch funding proposals to improve Tor exit IP address reputation, subjecting our user IP addresses to these systems seems anathema and unlikely.

In general, we vastly prefer cryptographic rate limiting approaches, or deterrents like our pow system[1], over blacklist-based approaches.

Now, if there were ideas being kicked around to cryptographically blind this data such that IP addresses were not revealed to anyone until they appear in multiple DoS event logs, that might be of interest.

1. proposals/327-pow-over-intro.txt · main · The Tor Project / Core / Tor Specifications · GitLab

···

On 7/13/23 20:23, Cory Francis Myers wrote:

On 2023-07-05 12:50, Mike Perry wrote:

--
Mike Perry
_______________________________________________
tor-project mailing list
tor-project@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

4

Thanks very much for this summary, Mike. It sounds like there is a clear division between (a) attacks targeting onion services, to be mitigated by the proof-of-work defense; and (b) attacks with a clearnet source or target, to be mitigated by this new work in progress.

For the latter, could there be value in a mechanism that allows nodes (especially relays) to coordinate either local or upstream blocking of traffic from D/DoS sources? This is the potential application I’m investigating of the IETF DOTS standard. But it may be an approach you’ve either already selected or ruled out.

     --- cfm.

···

On 2023-07-05 12:50, Mike Perry wrote:

The most common attack has been either onion service related, or
against the directory authorities. However, over the past year, we saw
several attack attempts that appeared to target specific relays. This
was a new phenomenon, at this scale.

[…]

Since the majority of DDoS activity has been onion service related, we
expect [the proof-of-work] defense to act as a deterrent there, for most
of the issues we have seen.

[…]

We recently obtained funding to fix these kinds of specific attacks
against Guards, dirauths, and Exits, but many issues will remain
confidential until we do so. We do not want to advertise which of
these probing attacks were actually effective vs not, or why.

--
Cory Myers
0x0F786C3435E961244B69B9EC07AD35D378D10BA0
_______________________________________________
tor-project mailing list
tor-project@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

5

Most the probing attacks against relays that we saw probed for resource
exhaustion conditions, which we will address via those conditions
themselves. We did get a report of at least one instance of the typical UDP
reflection flood against a Tor relay, though. It was quite large, but we
only heard this report from one relay operator (and there are several
thousand relay operators).

Thanks for clarifying, Mike. This is the more-generic class of attack
against which the DOTS standard would be most useful---which means it
probably won't be, for Tor relays, even apart from your caveat below.

It is unlikely for us to get directly involved in IP address blacklist or IP
address reputation games. Tor user experience is significantly degraded by
these systems. While we are trying to pitch funding proposals to improve Tor
exit IP address reputation, subjecting our user IP addresses to these
systems seems anathema and unlikely.

Understood. Were this method to be effective, would you extend this
objection even to coordinated *short-term* (requested/cancellable)
mitigation, in contrast to a cumulative, long-lived reputation scheme?

In general, we vastly prefer cryptographic rate limiting approaches, or
deterrents like our pow system[1], over blacklist-based approaches.

Now, if there were ideas being kicked around to cryptographically blind this
data such that IP addresses were not revealed to anyone until they appear in
multiple DoS event logs, that might be of interest.

Interesting! I will look into this approach as a possible extension of
the DOTS standard. Thanks for the suggestion.

  --- cfm.

···

On Fri, Jul 14, 2023 at 01:32:55AM +0000, Mike Perry wrote:

6

Most the probing attacks against relays that we saw probed for resource
exhaustion conditions, which we will address via those conditions
themselves. We did get a report of at least one instance of the typical UDP
reflection flood against a Tor relay, though. It was quite large, but we
only heard this report from one relay operator (and there are several
thousand relay operators).

Thanks for clarifying, Mike. This is the more-generic class of attack
against which the DOTS standard would be most useful---which means it
probably won't be, for Tor relays, even apart from your caveat below.

It is unlikely for us to get directly involved in IP address blacklist or IP
address reputation games. Tor user experience is significantly degraded by
these systems. While we are trying to pitch funding proposals to improve Tor
exit IP address reputation, subjecting our user IP addresses to these
systems seems anathema and unlikely.

Understood. Were this method to be effective, would you extend this
objection even to coordinated *short-term* (requested/cancellable)
mitigation, in contrast to a cumulative, long-lived reputation scheme?

I think where this is most likely to happen is at ISPs that relay operators use, for things like the UDP reflection attacks, rather than
the relays themselves.

David told me the other day that OVH actually stops such attacks against his relay every few weeks or so, so they might be more common than I realized, but just handled upstream in most cases.

The problem with trying to apply this to Tor itself is that
  a) We need to focus our limited dev resources on addressing existing
     resource exhaustion bottlenecks that have been targeted, rather than
     reporting mechanisms, at least for the short and medium-term.
  b) It is possible for legitimate activity to trip the rate limits that
     we have in place on Tor relays today, occasionally. We do not want
     to broadcast such IP addresses, as they might actually be legitimate
     users.

The cryptographic blinding idea I mentioned below would help with b, though. If some mechanism existed such that an IP was not revealed until it started tripping the limits of many relays, then this more strongly indicates that it is actually an attacker.

There are some ideas in Free Haven's Selected Papers in Anonymity, if you search for Nymble, BLAC, and Blacklisting. It has been a while since this literature has been reviewed or updated for ECC even, though, so I don't have great recommendations atm :confused:

···

On 7/19/23 15:43, Cory Francis Myers wrote:

On Fri, Jul 14, 2023 at 01:32:55AM +0000, Mike Perry wrote:

In general, we vastly prefer cryptographic rate limiting approaches, or
deterrents like our pow system[1], over blacklist-based approaches.

Now, if there were ideas being kicked around to cryptographically blind this
data such that IP addresses were not revealed to anyone until they appear in
multiple DoS event logs, that might be of interest.

Interesting! I will look into this approach as a possible extension of
the DOTS standard. Thanks for the suggestion.

  --- cfm.

--
Mike Perry
_______________________________________________
tor-project mailing list
tor-project@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project