[tor-project] Save the date: Berlin meetup Sep 9 - Sep 11
Tim Wilson-Brown - teor
teor2345 at gmail.com
Sat Jul 9 23:14:45 UTC 2016
> On 9 Jul 2016, at 07:03, dawuud <dawuud at riseup.net> wrote:
> Hey Aaron,
> there's this; it's a work in progress
> I want to detect various types of attacks on the tor network.
The "detect partitions" script looks interesting:
It seems similar to this trac ticket:
And it seems to suffer from some of the issues I just described on that ticket:
* network load - running these tests as fast as you can puts significant load on the network
I think detect_partitions.py has an 0.2 second delay. I used 1 second when I did it.
* what if a relay is down, rather than blocked?
This might be able to be detected using multiple runs, or using the consensus (after an hour).
Of course, if the script itself brings the relay down...
* making ~7000 connections through a single relay might overload it, particularly if it's low-bandwidth, file-descriptor limited, or behind a NAT box
I think detect_partitions.py uses the same first relay for all ~7000 second relays, then switches to another. This might cause connections through that relay to fail after a few hundred or thousand rapid attempts. But there's a "key" variable that could be used to permute this order.
Also, you might want to consider using only "Fast" relays, to avoid overwhelming low-end boxes, middleboxes, or networks.
* connection testing is directional - sometimes relay A can initiate a connection to relay B, but relay B can't initiate a connection to relay A. But once they're connected, they can both exchange cells.
I have no idea how to find out if a connection only works one way. Particularly when connections that are already open are bidirectional.
Do multiple tests on different days with different orders?
I think detect_partitions.py always uses the same order - it would be interesting to see if you get different results with the order inverted.
> On Fri, Jul 08, 2016 at 12:51:02PM -0400, Aaron Johnson wrote:
>> Hey David,
>>> I'm also working on a couple of projects to gather metrics about
>>> the tor network.
>> I’m interested in hearing more about what metrics you want to gather. Privacy-preserving metrics on Tor is something I have been working on lately. I won’t be at the Berlin meetup, unfortunately, although I should be at Tor dev in Seattle.
>> tor-project mailing list
>> tor-project at lists.torproject.org
> tor-project mailing list
> tor-project at lists.torproject.org
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the tor-project