Thus spake coderman (coderman@xxxxxxxxx): > On 7/18/07, Roger Dingledine <arma@xxxxxxx> wrote: > >On Wed, Jul 18, 2007 at 01:36:02AM -0700, Mike Perry wrote: > >> 1. Expand MAX_BELIEVABLE_BANDWIDTH from 1.5MBytes/sec to 10Mbytes/sec. > >... > >It's true that this doesn't distribute load ideally, but putting the > >cap lower than some of the running routers can prevent an attacker from > >publishing a majority of absurdly fast routers and pushing every guard > >guard out of having guard status -- similar to the attack described > >in ...uptime-sanity-checking.txt > > we were just discussing this today in #tor. router "ghettogear" > consistently averaged 210-260KB/sec for weeks. then on the 14th/15th > it went to 20.5MB/sec. [likely too obvious] it then dropped to > 6.1MB/sec; still enough to sit at the top of the node bw list (next > closest, blutmagie, is at 5.6MB/sec). Notice how just this one node lying was caught. Imagine sufficient numbers to drown out *all* current guards. Imagine the impact on the tor network speed if the adversary didn't have the capacity to properly relay all this traffic. Someone would notice. Right away, without scanning mechanisms. And with respect to drowning out guards, all the limit prevents us from doing is losing these 32 guards who have more than 1.5MBytes/sec. And they would be weighted equally with all the adversary's other ~500 nodes to drown out the median with 1.5Mbyte nodes under the current system. This is no protection. The guard speed limit to prevent this sort of attack needs to be split off, and made much lower. > so defending against this kind of thing may be useful now, not just in > the future. :) The mechanisms are built. All we need is people to scan. If you would like, I can show you how to run scans via TorFlow and monitor the results. It is hard for me to juggle scanning continuously right now by myself, I work a full time job and have 2 Tor projects going :). I could use some help. > (also, there are only 32 nodes that are getting clipped right now at > 1.5, so i don't see raising to 10 giving much improvement.) It causes the effective loss of N-1.5Mbytes/sec of total Tor bandwidth.. > >Actually, I just checked the code, and that attack works right now. :( > >We should consider modifying router_get_advertised_bandwidth() to cap > >its answer at MAX_BELIEVABLE_BANDWIDTH, so the smartlist we build in > >dirserv_compute_performance_thresholds() won't list the higher bandwidths. > > does this mean that clipping prevents the attack inside > smartlist_choose_by_bandwidth, but the directory servers are still > exposed because of the way they compute thresholds, in turn affecting > guard / stable selection? Yeah, the limit should be split and lowered. 1.5Mbyte/sec does not defend against guard selection attacks, as I mentioned above. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpvojT1wO9PA.pgp
Description: PGP signature