Save the date: Berlin meetup Sep 9 - Sep 11
Hi, it seems we have a winner for the proposed Berlin meetup later this year: September 9 - September 11. While not everybody can attend all days this is the weekend where everybody can attend at least one day. I am about to send further information to the tor-meeting list. If you are not subscribed to it yet, now would be a good time I guess. :) Georg
Georg Koppen:
it seems we have a winner for the proposed Berlin meetup later this year: September 9 - September 11. While not everybody can attend all days this is the weekend where everybody can attend at least one day.
I am about to send further information to the tor-meeting list. If you are not subscribed to it yet, now would be a good time I guess. :)
Hi, would it make sense for someone from Tails to attend? Do you have more info about the content and objectives of the meetup? I'm also not sure what tor-meeting is about, but if you think that it would also make sense for someone from Tails to be there, feel free to subscribe me (or I can do it myself if it's open).
Hi Sajolida, Hi tor-project mailing list, Certainly it is dissappointing that the tor-dev meeting will not be in Europe this time. I live in Berlin and if you come to the Berlin meetup we can chat about little-t tor's broken control port security model and how filter daemons like roflcoptor fix this problem. I'm also working on a couple of projects to gather metrics about the tor network. hmm what else? - Tails might be interested to know about the Tahoe-LAFS tor integration and the Magic-Folder project + GridSync GUI projects. - tor integration related features for Subgraph OS. We're working on improvements to fw-daemon and oz. Cheers! David
Hi, would it make sense for someone from Tails to attend? Do you have more info about the content and objectives of the meetup?
I'm also not sure what tor-meeting is about, but if you think that it would also make sense for someone from Tails to be there, feel free to subscribe me (or I can do it myself if it's open).
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. Best, Aaron
Hey Aaron, there's this; it's a work in progress https://github.com/TheTorProject/bwscanner I want to detect various types of attacks on the tor network. Cheers, David 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.
Best, Aaron
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Great, thanks! I think improved BW scanning is important and interesting work. If there’s a mailing-list thread or any documentation outside the codebase, I’d be interested to read that as well. Best, Aaron
On Jul 8, 2016, at 5:03 PM, dawuud <dawuud@riseup.net> wrote:
Hey Aaron,
there's this; it's a work in progress https://github.com/TheTorProject/bwscanner
I want to detect various types of attacks on the tor network.
Cheers, David
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.
Best, Aaron
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On 9 Jul 2016, at 07:03, dawuud <dawuud@riseup.net> wrote:
Hey Aaron,
there's this; it's a work in progress https://github.com/TheTorProject/bwscanner
I want to detect various types of attacks on the tor network.
The "detect partitions" script looks interesting: https://github.com/TheTorProject/bwscanner/blob/develop/bwscanner/detect_par... It seems similar to this trac ticket: https://trac.torproject.org/projects/tor/ticket/19068 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. Tim
Cheers, David
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.
Best, Aaron
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n
Dear Tim, See? This is why we need documentation like Aaron Johnson asked for. It was Aaron Gibson's project and several months ago Leif, Donncha and I participated in design discussion with Aaron. It's been months since I worked on this project but I can tell you that our design discussions didn't have the shitty design where you hose the tor relays with 7000 sequential connections. When Daira Hopwood came to the onion space here in Berlin I specifically asked her to help us by designing an algorithm for lazily generating unordered/randomly-ordered lists of 2 hop circuits with a partitioning scheme so that the total list is made up of several list partitions which can be computed in parallel. Which is why we put this in the CHANGELOG: """ Daira Hopwood - Wrote the algorithm for lazily generating tor circuit permutations, with parallelizeable partitioning scheme optimized for low CPU and memory consumption. """ I'm sorry the code is sloppy and buggy right now. It's perfectly understandable that you would write this e-mail to me because some of the code is obviously not written correctly... and we have no docs so how would you have known we don't intend to hose the tor network ;-p In a few days I'm going to Croatia to go sailing with some friends. I'll be gone for a few weeks. When I get back I'll try to work on this some more. Donncha and Meejah can also merge pull requests for this project. Tim, Thanks for pointing out that trac ticket btw. I was unaware of it. Cheers, David On Sun, Jul 10, 2016 at 09:14:45AM +1000, Tim Wilson-Brown - teor wrote:
On 9 Jul 2016, at 07:03, dawuud <dawuud@riseup.net> wrote:
Hey Aaron,
there's this; it's a work in progress https://github.com/TheTorProject/bwscanner
I want to detect various types of attacks on the tor network.
The "detect partitions" script looks interesting: https://github.com/TheTorProject/bwscanner/blob/develop/bwscanner/detect_par...
It seems similar to this trac ticket: https://trac.torproject.org/projects/tor/ticket/19068
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.
Tim
Hi, sajolida:
Georg Koppen:
it seems we have a winner for the proposed Berlin meetup later this year: September 9 - September 11. While not everybody can attend all days this is the weekend where everybody can attend at least one day.
I am about to send further information to the tor-meeting list. If you are not subscribed to it yet, now would be a good time I guess. :)
Hi, would it make sense for someone from Tails to attend? Do you have more info about the content and objectives of the meetup?
There is not much more than "A meeting of Tor people in Berlin to socialize, discuss, work and have fun together." yet. I've heard there will be metrics people there discussing future work but apart from that nothing is set yet. https://trac.torproject.org/projects/tor/wiki/org/meetings/2016BerlinMeetup/... is currently empty as well. Feel free to fill stuff in that you want to get done there. Or just come to the meeting and I bet we'll find something to work on. :)
I'm also not sure what tor-meeting is about, but if you think that it would also make sense for someone from Tails to be there, feel free to subscribe me (or I can do it myself if it's open).
That's the list for attendees of Tor's periodic in-person meetings. Thus, I think it makes sense to have someone from Tails subscribed to it. It's an open list, so feel free to do so (not sure if it is you or if it should be someone else from Tails). Georg
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/07/16 10:35, Georg Koppen wrote:
sajolida:
Georg Koppen:
it seems we have a winner for the proposed Berlin meetup later this year: September 9 - September 11. While not everybody can attend all days this is the weekend where everybody can attend at least one day.
I am about to send further information to the tor-meeting list. If you are not subscribed to it yet, now would be a good time I guess. :)
Hi, would it make sense for someone from Tails to attend? Do you have more info about the content and objectives of the meetup?
There is not much more than "A meeting of Tor people in Berlin to socialize, discuss, work and have fun together." yet. I've heard there will be metrics people there discussing future work but apart from that nothing is set yet.
https://trac.torproject.org/projects/tor/wiki/org/meetings/2016BerlinMeetup/...
is currently empty as well. Feel free to fill stuff in that you want to get done there. Or just come to the meeting and I bet we'll find something to work on. :)
There, made a start by adding some ideas. Expect more the closer we get to the date. But don't let that stop you from adding more ideas in the meantime. ;) All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXhg0KAAoJEC3ESO/4X7XBSTUH/jYayMypqQ/ziilLw+0jYlL7 XLVzVk/p0Qz4P8yXev7mgjpoH4G8CHUrUEQDr/XdbRyQPI4AWKTg/cukqyc6kciy VhFTdCax9qrC4I1eMPAitCeee6gBV/dkwn/AcLL6k2wfMji8H+4xqwXV3XOiN0zY XkVATiB6d3CiCxtDkk+H7dDsQYuNE4hlzTx3mQMHKWX+FdUBSBTI+Fa+Ig/bXxfL LcPWBF0UtwxDGEK3ZFYXfXZYsbqnb1nL3YLy9XX8D0WP/mhexvGCa7UKlvO1mROx X747aOutMUFb/KaiovBKg1FuZSflLIkSIKfEDe8L16W3OaYvlttqhTL4LkS3vms= =d8Hz -----END PGP SIGNATURE-----
Georg Koppen:
sajolida:
Georg Koppen:
it seems we have a winner for the proposed Berlin meetup later this year: September 9 - September 11. While not everybody can attend all days this is the weekend where everybody can attend at least one day.
I am about to send further information to the tor-meeting list. If you are not subscribed to it yet, now would be a good time I guess. :)
Hi, would it make sense for someone from Tails to attend? Do you have more info about the content and objectives of the meetup?
There is not much more than "A meeting of Tor people in Berlin to socialize, discuss, work and have fun together." yet. I've heard there will be metrics people there discussing future work but apart from that nothing is set yet.
https://trac.torproject.org/projects/tor/wiki/org/meetings/2016BerlinMeetup/...
is currently empty as well. Feel free to fill stuff in that you want to get done there. Or just come to the meeting and I bet we'll find something to work on. :)
Understood, thanks!
I'm also not sure what tor-meeting is about, but if you think that it would also make sense for someone from Tails to be there, feel free to subscribe me (or I can do it myself if it's open).
That's the list for attendees of Tor's periodic in-person meetings. Thus, I think it makes sense to have someone from Tails subscribed to it. It's an open list, so feel free to do so (not sure if it is you or if it should be someone else from Tails).
So I subscribed!
participants (6)
-
Aaron Johnson -
dawuud -
Georg Koppen -
Karsten Loesing -
sajolida -
Tim Wilson-Brown - teor