DoS Session, Friday

  • How do we prioritize the different attacks and defenses they/we can apply to the Tor network?

Sniper Attacks

Rob describes the sniper attack.

Roger explains the OOM handler in Tor where we zap the problematic circuits. The attack is largely unproblematic now, but you can still use large amounts of bandwidth. We also have a maximum number of cells that can wait on the circuit.

A client that doesn't use SENDME cells should be considered malicious.

Check relays that have GUARD or FAST/EXIT flags and whether they are doing the attack. The attack is more easy to fire off as a client than being an exit.

The should be considered a DoS against both the middle, the exit, and the network itself.

The current cells limit is 50k (8k on moria) of cells on the circuit queue before we start killing circuits. Only relay data cells are counted in the window, but does get queued up and because it's in the middle we can't do anything about it.

The attack is still ongoing, but we don't know if it's malicious.

Authenticated sendme cells

Designed by Rob and Roger. Roger explains how the authenticated sendme works. It could make sense to have a short cell where some data includes randomness outside of the payload to force the client to read all data that is coming in to compute the rolling hashes.

Should we use SHA-1 here? Probably not problematic :-)

HSv3 uses SHA-3 for its rolling digest.

The authenticated sendme cells are symmetric (both directions of the circuit).

What is the state of authenticated sendme's

  • The proposal has been written.
  • Roger thinks it's right.
  • Different kind of possible sybil attacks.
  • The cost is increased.

David's patch helps when someone shows up with a lot of clients from the same source IP.

How does the exit node know if the clients supports authenticated sendme? One possible option is to update the circuit protocol version used in the extended cells to let the exit know that the client support this. In "theory" it is a simple patch that could be moved into 0.2.9.x.

Action items

  • This have been added to the roadmap for the network team with dgoulet + teor + arma. Should fit under sponsor V. (#26288)

Connection reconnect cache

David explains his patch that adds a cache to Tor where we check the cache if we have tried connecting to a relay recently unsuccessfully and block it.

Action items

  • We should probably log in the heartbeat how many (re)connect attempts we have blocked using the cache. (#26290)

Prioritizing DoS attack mitigation

  • Standardize monitoring and investigation of DoS attacks.
  • We add some new rules to the security heuristics that have to do with DoS such that we can reuse them from the security policy. High could be considered "taking down the network"
  • Document how we handle security issues and how to handle them in secret/public? See the protover security issue as an example.

DirPort connection load

  1. Start dumping information about this from relays.
  2. Are we able to replicate this in a experiment on our own machine.
  3. Are these clients "real clients"/"real relays"/"real bridges"? For relays: Are they in the consensus?

Action items

  • Could we have a subsystem where we can query about connection information? Sounds like rephist isn't that useful in this situation. (#26292)
  • Educate relay operator to be able to spot and debug issues. Build a group of people that can help others do that. A forensics team under the relay operator team. (Contact Colin)
Last modified 2 years ago Last modified on Jun 3, 2018, 6:24:45 PM