> On 3 Dec. 2016, at 11:48, Bungeetaco <bungeet...@protonmail.com> wrote: > > Hi there, I have added the following line to the torrc of all my tor nodes > and reloaded the daemons: > > MyFamily > 629FE436746E0AACDFC93D2DA70B5E269F7ADC79,DA5B2F8C1C7E901374C8A200277A3C927176BF0F,A894ABB7B1A990B5F10BA9CBE668E27BE6C7FEDF > > Been running my two exit nodes for a year now with good management, and I > haven't got raided so far so I guess I'm doing this the right way. Glad you > guys are reaching out about issues that are easily fixable by operators > instead of just blacklisting nodes at random. > If something else needs my attention, feel free to let me know. I love this > project ^w^/.
Thanks for fixing this so quickly. It should be distributed to all clients within the next few hours. You can check it worked using the "Family Members" on: https://atlas.torproject.org/#details/629FE436746E0AACDFC93D2DA70B5E269F7ADC79 It will take at least 15 minutes to appear on atlas, and maybe even 75 minutes, if your relays sent updated descriptors after 50 minutes past the hour. Tim > >> -------- Original Message -------- >> Subject: Re: [tor-dev] protecting users from known relay groups with >> end-to-end correlation capabilities >> Local Time: December 2, 2016 7:15 PM >> UTC Time: December 3, 2016 12:15 AM >> From: teor2...@gmail.com >> To: Bungeetaco <bungeet...@protonmail.com> >> tor-dev@lists.torproject.org <tor-dev@lists.torproject.org> >> >> >> > On 3 Dec. 2016, at 11:11, Bungeetaco <bungeet...@protonmail.com> wrote: >> > >> > >> > >> > >> > >> > >> > Hi there! I would be more than glad to apply the appropriate modifications >> > to my relay if it means increased security for the users ;D. I care about >> > the security and privacy of the people who pass through my relays, and I >> > take pride in supporting a project which empowers people so much. I >> > decided to run a Middle and 2 exit nodes because I wanted to provide >> > diversified support to the Tor network, I did not intend to jeopardize >> > anyone's privacy or security. >> > >> > Would I need to add the fingerprints of my others nodes in my torrc >> > configuration files? If so, please let me know how to accomplish this and >> > I'll push an update on all my servers ASAP. The last thing I want is >> > create a security risk for the users and/or distrust. >> > >> > Thanks for letting me know about this btw! >> >> Hi Bungeetaco, >> >> On each relay, add a line to the torrc that says: >> >> MyFamily fingerprint,fingerprint,fingerprint,... >> >> Where the fingerprints are the fingerprints of each of your relays. >> >> Tim >> >> > - Bungeetaco >> > https://bungeetaco.com/ >> > >> >> -------- Original Message -------- >> >> Subject: Re: [tor-dev] protecting users from known relay groups with >> >> end-to-end correlation capabilities >> >> Local Time: December 2, 2016 5:39 PM >> >> UTC Time: December 2, 2016 10:39 PM >> >> From: teor2...@gmail.com >> >> To: tor-dev@lists.torproject.org >> >> ab...@torworld.org, t...@digineo.de, Viktor Nikolov >> >> <vniko...@vnikolov.cz>, Nicholas Merrill <n...@calyx.com>, >> >> bungeet...@protonmail.com, Dmitrii Tcvetkov <demfl...@demfloro.ru>, >> >> ab...@to-surf-and-protect.net, bad-rel...@lists.torproject.org >> >> >> >> Dear relay operators who are CC'd, >> >> >> >> TL;DR: we're talking about blacklisting your non-exit relays, >> >> because they don't have MyFamily set correctly. >> >> >> >> If you'd like help configuring MyFamily correctly, please let us know. >> >> >> >> > On 3 Dec. 2016, at 08:50, nusenu <nus...@openmailbox.org> wrote: >> >> > >> >> > Hi, >> >> > >> >> > it is a well known fact that MyFamily is a largely ignored setting, >> >> > luckily this is not a problem in most cases because >> >> > >> >> > - all relevant relays are run in a single /16 >> >> > or >> >> > - are only guard relays (exit probability = 0*) >> >> > or >> >> > - are only exit relays (guard probability = 0*) >> >> > >> >> > but there is a limited number of relay groups** that have actual >> >> > end-to-end correlation capabilities, meaning they are potentially chosen >> >> > by tor clients for the guard _and_ exit position, even if the odds are >> >> > (hopefully) not very high. >> >> > >> >> > These potentially dangerous relay groups >> >> > - are run in multiple /16 netblocks >> >> > - have an exit _and_ guard probability of > 0 (because they run exits >> >> > and guards) >> >> > >> >> > Examples (generated daily): >> >> > https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt >> >> > (see CC) >> >> >> >> This is a useful check, but it is insufficient. >> >> Can you please produce a similar list for middles and exits by the same >> >> operator? >> >> >> >> (Controlling the middle and exit leads to a guard identification >> >> attack.) >> >> >> >> There's also an attack when an operator controls a guard and a middle. >> >> But that's harder to resolve, albeit much more common. >> >> >> >> > How could the risk for tor clients be reduced? >> >> > (options after enough dir auths came to the conclusion that these relays >> >> > are in fact operated by a single entity) >> >> > >> >> > 1) try to contact the operators and give them time to fix it >> >> > I've done that multiple times but haven't been successful [1] >> >> >> >> Have you tried emailing them individually? >> >> I've typically got better results that way. >> >> >> >> > 2) build tools to easily/automatically manage MyFamily >> >> > done[2], but it is unlikely to be used >> >> >> >> Maybe one solution is to build a generic tool that works with more than >> >> just ansible? >> >> >> >> > 3) assign them the badexit flag >> >> > since exits are a scarce resource, not very wise >> >> >> >> +1 >> >> >> >> > 4) assign them the badguard flag >> >> > there is no such thing ;) >> >> >> >> We have written patches that take away the guard flag. >> >> This would be possible, but it doesn't resolve the issue, because they >> >> will still be used as middle relays. >> >> >> >> However, taking away the guard flag would fix the guard/middle case, >> >> because then all the relays would only be used as middle relays. >> >> >> >> > 5) blacklist the entry guards (that are outside the configured family) >> >> >> >> Yes, this is the best option, because it protects clients from >> >> selecting relays from that operator as either guard or middle. >> >> >> >> (However, operating a bridge and an exit still has the same issue, and >> >> there is no MyFamily for bridges, because that de-anonymises them. As >> >> do the bridge/middle and guard/middle cases. So maybe we should >> >> consider the risks of each case, and whether we want to educate or ban.) >> >> >> >> And, of course, it's worth noting that the ContactInfo might be >> >> incorrect, so we would have to do this on a case-by-case basis, and >> >> convince the directory authority operators it's a sensible thing to do. >> >> >> >> (If someone is using others' ContactInfo, those relays should be >> >> banned.) >> >> >> >> > 6) change tor's path selection algorithm to never choose more than one >> >> > relay with a given non-empty non-default contact string? >> >> > This would basically turn the ContactInfo field into the PoS token >> >> > mentioned by Mike in [3]. Since there are a few common contactInfo >> >> > strings this is probably not the best option without excluding them. >> >> >> >> No, this field is not mutually authenticated, unlike MyFamily. >> >> This leads to an attack where bad relays bias client path selection >> >> using ContactInfo. >> >> >> >> > [1] >> >> > https://lists.torproject.org/pipermail/tor-relays/2016-November/010965.html >> >> > [2] https://github.com/nusenu/ansible-relayor >> >> > [3] https://trac.torproject.org/projects/tor/ticket/5565 >> >> > * if we can assume onionoo's values to be accurate and realistic >> >> > ** they are considered to be operated by a single group due to their >> >> > contactInfo descriptor field. This string is not verified in any way and >> >> > can therefore result in false-positives. 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 ------------------------------------------------------------------------ _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
