|
|
== 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) |