> 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 >> ------------------------------------------------------------------------ >> >> >> > 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
