tor-dev May 2017

tor-dev@lists.torproject.org

21 participants
25 discussions

Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?
by Sebastian Hahn 09 May '17

09 May '17

Dear all, below mail was meant to make it to tor-dev, but I got a bounce and didn't notice until now. Whoops, my apologies. > On 8. Dec 2016, at 14:29, Sebastian Hahn <tor(a)sebastianhahn.net> wrote: > > Hi, > >> On 08 Dec 2016, at 14:03, nusenu <nusenu(a)openmailbox.org> wrote: >> >> Dear tor directory authorities, >> >> TLDR: Would you blacklist relays with end-to-end correlation capabilities? >> >> I'm asking to find out whether it makes sense to put any effort into >> finding such operators [2]. If most dir auths would not blacklist such >> relays than it does not make sense to look for them I guess. >> >> So please let us know whats your opinion on that - thank you. >> >> >> More information below and there [1]: >> >> >> The process could look something like this: >> >> - someone identifies such a relay groups (basically based on contactinfo >> [2]) >> - contact the operators asking to fix this (ideally this would be a >> @torproject.org sender) >> - give them 15 days to fix it >> - if not fixed: blacklist respective guard relays >> - give them the possibility to get removed from the blacklist once fixed > > I do not think that this is worthwhile. It establishes a precedent where > setting your contact info is something that gets you banned, potentially > incorrectly because it's unauthenticated, whereas we're unable to identify > people who actually maliciously run several relays without such indicators. > > Additionally, it's yet one more thing to update the dirauths' configs > for, but with rather more overhead as we might get multiple mails back > and forth about how MyFamily is annoying to maintain, how they're just > trying to help, etc. All not so bad arguments. > > If we did this, also why would we blacklist the nonexit relays? That > seems to not make sense, as a relay operator could have multiple relays > that act as guard and exit simultaneously. I think we'd need to > blacklist at least all the exit relays, if not all of them. BadExiting > them would then be the more sensible choice. Scarcity of resources has > in the past led us to bad designs like Valid/Invalid relays etc, which > causes way more annoyances than good things. > > Cheers > Sebastian Cheers Sebastian

1 0

Re: [tor-dev] [tor-commits] [tor/master] Bug 17592: Clean up connection timeout logic.
by Roger Dingledine 09 May '17

09 May '17

On Mon, May 08, 2017 at 06:00:18PM +0000, nickm(a)torproject.org wrote: > commit d5a151a06788c28ac1c50398c6e571d484774f47 > Author: Mike Perry <mikeperry-git(a)torproject.org> > Date: Tue Feb 21 21:28:00 2017 -0500 [...] > + - Increase the intial circuit build timeout testing frequency, to help > + ensure that ReducedConnectionPadding clients finish learning a timeout > + before their orconn would expire. The initial testing rate was set back > + in the days of TAP and before the Tor Browser updater, when we had to be > + much more careful about new clients making lots of circuits. With this > + change, a circuit build time is learned in about 15-20 minutes, instead > + of ~100-120 minutes. Fyi, the current Tor network has "cbttestfreq=60" set in its consensus params. Is this something we should change? --Roger

2 1

Chutney Default: DNS or Offline?
by teor 07 May '17

07 May '17

Dear chutney users, Do you use DNS with chutney? (Chutney uses IP addresses by default.) Chutney has never worked offline, because Tor Exits check DNS before publishing their exit policy. And if DNS fails while a test is being run, chutney fails. (See Tor bug #21900.) We can make chutney work offline by disabling DNS. See the chutney bug at: https://trac.torproject.org/projects/tor/ticket/21903 But we need to decide what the default is: Do you want chutney to work offline by default? Or do you want chutney to have working DNS by default? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

making sure I configure OutboundBindAddressExit correctly
by nusenu 05 May '17

05 May '17

Hi, since I really like this new feature I added [1] initial autoconfiguration support for it to ansible-relayor (user can opt-in via a single boolean and we automate the rest). I want to make sure I do this correctly and would like your feedback on the following questions: a) Is 'OutboundBindAddressOR' in the following context optional (in the sense that it does not change tor's behavior)? ExitRelay 1 ExitPolicy reject *:25,accept *:* ORPort 1.2.3.4:9001 OutboundBindAddress 1.2.3.4 OutboundBindAddressOR 1.2.3.4 OutboundBindAddressExit 7.7.7.7 is identical to: ExitRelay 1 ExitPolicy reject *:25,accept *:* ORPort 1.2.3.4:9001 OutboundBindAddress 1.2.3.4 OutboundBindAddressExit 7.7.7.7 (since according to the manual page OutboundBindAddress*OR* would just override OutboundBindAddress, which is not needed in the above example since they match) b) Is it ok to set OutboundBindAddressExit for IPv4 only, even if we set 'IPv6Exit 1' or is setting an IPv6 OutboundBindAddressExit address required after setting OutboundBindAddressExit for IPv4? Since this question might be a bit confusing I'll give an example in form of torrc lines: ORPort 1.2.3.4:9001 OutboundBindAddress 1.2.3.4 OutboundBindAddressExit 7.7.7.7 IPv6Exit 1 ExitRelay 1 ExitPolicy reject *:25,accept *:* (this config has an IPv4 OutboundBindAddressExit entry but no IPv6 OutboundBindAddressExit entry) c) Similar to (b) is it ok to enable OutboundBindAddressExit for IPv6 only? d) Is it ok if multiple tor instances on the same host use the same OutboundBindAddressExit address? (ignoring the fact that big exits might run out of source ports?) thanks, nusenu [1] https://github.com/nusenu/ansible-relayor/commit/00fa7c571e8b6f6256092d9928… -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 2

Leekspin and Stem descriptor creation
by Damian Johnson 02 May '17

02 May '17

Hi Isis. For kicks and giggles this weekend I added the ability for Stem to create descriptors... https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#can-i-… https://gitweb.torproject.org/stem.git/commit/?id=b2a54ad This is something Stem has always been able to do but it was buried in our testing helpers. Now descriptor subclasses have a static create() and content() method. This *doesn't* yet support signing descriptors. I'm looking into that next. To that end I took a peek today at leekspin (https://pypi.python.org/pypi/leekspin) and... damn. Beautiful work! Besides the crypto are there any other aspects of your library you think we should incorporate? Cheers! -Damian

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev May 2017