[tor-relays] announcing new exit relays run by Digitalcourage in Germany

[Christian Pietsch]

Dear Tor friends,

Digitalcourage has launched a cluster of new relays on Sunday, and we
just turned them into exit relays. We hope they will be pretty fast.
They are running on new server metal with a nice connection to the
Internet. Nicknames and their fingerprints are as follows:

Digitalcourage4ip1a – Fingerprint 97F51AF6791AD33981CE25DC7A2618429F25B3B0
Digitalcourage4ip1b – Fingerprint BB034C34ED9E60F7709ED93FB432A9BA12A2F2B6
Digitalcourage4ip2a – Fingerprint 68EC657DC8A587B38D5D7763D5C72E93C2CD456C
Digitalcourage4ip2b – Fingerprint BA9D7FB9AB4ED0FBCA56941DA22CF7770BA1A4BC
Digitalcourage4ip3a – Fingerprint A2DD0EF31813E9B7F6DB435504A406E1AD2B76AB
Digitalcourage4ip3b – Fingerprint 35B503FB546815CC9EDE91022555B5D0ED04E389
Digitalcourage4ip4a – Fingerprint FDCFEA18CC64461455DE5EA3FC31834C6B42FEC7
Digitalcourage4ip4b – Fingerprint 8287DADC415B3E667C617EEFB6E7D654C7AC0C47
Digitalcourage4ip5a – Fingerprint 9AD90317DDA2F898EB0AE0F20976EA97E7AF9012
Digitalcourage4ip5b – Fingerprint 902A13399F14FFC7E2912463300C78A25C1F76B6
Digitalcourage4ip6a – Fingerprint 6B61EFE3AEDEB3351FD3C910443D95556316E01C
Digitalcourage4ip6b – Fingerprint 762213D327B0A76057F4B61CD587ED4238CD900E
Digitalcourage4ip7a – Fingerprint 22296CB6AE56609A96F02FB843AB7B4B0A31CAF4
Digitalcourage4ip7b – Fingerprint D13692D97236C0B8E8E19EA2DD952B5C4F9010BB
Digitalcourage4ip8a – Fingerprint 844DC3890E4D04473D10EE65547491F200A86F89
Digitalcourage4ip8b – Fingerprint E2AE93904308E8EB4F8CAE3784D9424B78A4A596

For details, see https://digitalcourage.de/support/tor#gen4 (German
only for now, sorry).

Heartfelt thanks to everyone who helped us with advice, IP addresses,
connectivity, Tor, ansible-relayor, GNU/Linux, donations or membership
fees!

We will retire our old (generation 3) exit relays by the end of this
year. They served as fallback directory mirrors. I will soon write to
gus to tell him which new fingerprints could replace them.

Cheers,
Christian

-- 
Christian Pietsch | volunteering for Digitalcourage e.V., Germany
Digitalcourage: https://digitalcourage.de/en
BigBrotherAwards Germany: https://bigbrotherawards.de/
Still using Google Docs? Try my CryptPad: https://cryptpad.uber.space


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[Anonforpeace]

I run a bridge. Does that count?

 Original Message 
On Jul 8, 2020, 1:36 PM, gus wrote:

> Dear Relay Operators,
>
> Do you want your relay to be a Tor fallback directory mirror?
> Will it have the same address and port for the next 2 years?
>
> Just reply to this email with your relay's fingerprint.
>
> Important: you have until July 23 2020 to reply to this message to get
> in the fallback directory mirror list.
>
> If your relay is on the current fallback list, you don't need to do
> anything.
>
> If you're asking:
>
> Q: What's a fallback directory mirror?
>
> Fallback directory mirrors help Tor clients connect to the network. For
> more details, see [1].
>
> Q: Is my relay on the current list?
>
> Search [2] and [3] for your relay fingerprint or IP address and port.
> [2] is the current list of fallbacks in Tor.
> [3] is used to create the next list of fallbacks.
>
> Q: What do I need to do if my relay is on the list?
>
> Keep the same IP address, keys, and ports. Email tor-relays if the
> relay's details change.
>
> Q: Can my relay be on the list next time?
>
> We need fast relays that will be on the same IP address and port for 2
> years. Reply to this email to get on the list, or to update the details
> of your relay.
>
> Once or twice a year, we run a script to choose about 150-200 relays
> from the potential list [3] for the list in Tor [2].
>
> Q: Why didn't my relay get on the list last time?
>
> We check a relay's uptime, flags, and speed [4]. Sometimes, a relay
> might be down when we check. That's ok, we will check it again next
> time.
>
> It's good to have some new relays on the list every release. That helps
> tor clients, because blocking a changing list is harder.
>
> cheers,
> Gus
>
> [1]
> https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDirectoryMirrors
> [2]
> https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc
> [3]
> https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list
> [4]
> https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log
> --
> The Tor Project
> Community Team Lead
> http://expyuzz4wqqyqhjn.onion/
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[William Pate]

787atxdotme
7AC93EC4B3725ABF7E09A903BC4A5C5C1E36517F

787atxdotmeonpi4
BD187CF1B44A84EC7DD1BC2AC9C4F7DE23D16619


William Pate
willp...@pm.me
512-947-3311
inadequate.net

‐‐‐ Original Message ‐‐‐
On Wednesday, July 8, 2020 12:36 PM, gus  wrote:

> Dear Relay Operators,
>
> Do you want your relay to be a Tor fallback directory mirror?
> Will it have the same address and port for the next 2 years?
>
> Just reply to this email with your relay's fingerprint.
>
> Important: you have until July 23 2020 to reply to this message to get
> in the fallback directory mirror list.
>
> If your relay is on the current fallback list, you don't need to do
> anything.
>
> If you're asking:
>
> Q: What's a fallback directory mirror?
>
> Fallback directory mirrors help Tor clients connect to the network. For
> more details, see [1].
>
> Q: Is my relay on the current list?
>
> Search [2] and [3] for your relay fingerprint or IP address and port.
> [2] is the current list of fallbacks in Tor.
> [3] is used to create the next list of fallbacks.
>
> Q: What do I need to do if my relay is on the list?
>
> Keep the same IP address, keys, and ports. Email tor-relays if the
> relay's details change.
>
> Q: Can my relay be on the list next time?
>
> We need fast relays that will be on the same IP address and port for 2
> years. Reply to this email to get on the list, or to update the details
> of your relay.
>
> Once or twice a year, we run a script to choose about 150-200 relays
> from the potential list [3] for the list in Tor [2].
>
> Q: Why didn't my relay get on the list last time?
>
> We check a relay's uptime, flags, and speed [4]. Sometimes, a relay
> might be down when we check. That's ok, we will check it again next
> time.
>
> It's good to have some new relays on the list every release. That helps
> tor clients, because blocking a changing list is harder.
>
> cheers,
> Gus
>
> [1]
> https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDirectoryMirrors
> [2]
> https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc
> [3]
> https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list
> [4]
> https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log
>
> 
>
> The Tor Project
> Community Team Lead
> http://expyuzz4wqqyqhjn.onion/
>
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Please help us find a working alternative to using MaxMind's GeoLite2 databases

[Sebastian Elisa Pfeifer]

My relays:
* themerrythoughts is not on the list
* thesistersofmercy is neither on the list
* joydivision is located in RU, but is in UA
* projectpitchfork is not on the list
* thecure is not on the list
* bauhaus is not on the list
* clanofxymox is not on the list

lg
Sebastian

On 07/07/2020 11:19, Karsten Loesing wrote:
> On 2020-02-12 16:05, Karsten Loesing wrote:
>> Hi relay operators,
>>
>> as you might have heard, MaxMind has changed access and use of their
>> GeoLite2 databases:
>>
>> https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
>>
>> This affects Onionoo and tor, and I'm trying to find a working
>> alternative on the following ticket:
>>
>> https://trac.torproject.org/projects/tor/ticket/32978
>>
>> Today I think I found a possible alternative by using data from another
>> provider. But before I name it here, I'd first want to find out how
>> accurate it is.
>>
>> I tried resolving relay IP addresses of relays that have been running in
>> the past week and compared that to our existing lookups using MaxMind's
>> October database.
>>
>> The result is that 7669 relays (93%) had the same country code and ASN.
>>
>> I put the remaining 7% on the following wiki page:
>>
>> https://trac.torproject.org/projects/tor/wiki/doc/MetricsGeoipComparison
>>
>> I'd like to hear from you which data source is right and which is wrong
>> (or if both are wrong).
>>
>> If you'd like to help, please leave comments on the ticket or in the
>> "Comment" column on that wiki page by February 19, 2020.
>>
>> Thanks for helping!
> 
> Hello again,
> 
> I'm bumping this thread, because there's (finally) news on finding an
> alternative to MaxMind:
> 
> https://gitlab.torproject.org/tpo/metrics/trac/-/issues/32978
> 
> (Yes, you'll have to scroll down quite a bit to find the news, it's a
> long ticket.)
> 
> Can relay operators please take a look at that ticket and see if they
> find their relay in the table with different country results?
> 
> It would be neat to identify patterns there and possibly improve the
> accuracy of the new database.
> 
> Thanks for your help!
> 
> All the best,
> Karsten
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

-- 
Sebastian Elisa Pfeifer
Wehlistrasse 40/2/1
1200 Wien

PGP Key ID: 0x923719A753677B95

https://sebastian-elisa-pfeifer.eu

Phone (AT):+43 1 22 600 45
Phone (DE):+49 221 596 19 4570
Mobile: +43 699 195 79 087
Fax:  +43 1 22 600 45 - 10
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks

[Guinness]

Le Wed, Jul 08, 2020 at 05:22:44PM +0200, Toralf Förster écrivait :
> On 7/8/20 12:35 PM, Roger Dingledine wrote:
> > * One is dividing the network into known and unknown relays, where we
> > reserve some minimum fraction of attention for the known relays. Here
> > the next steps are to figure out how to do load balancing properly with
> > this new parameter (mainly a math problem), and to sort out the logistics
> > for how to label the known relays so directory authorities can assign
> > weights properly (mainly coding / operator ux).
> 
> Which boils down to "subjective" versus "objective" criterias of a weight 
> distribution algorithms.
> 
> Which is fine as long as the maths behind it is public available and 
> understandable.
> 
> This would enable a relay operator to verify/falsify it.
> 

I'm pretty sure the maths behind it will be public. For the
"understandable" part, I guess there can be a double explanation, one
for the mathematicians/CS that know/understand the maths, and a
popularisation of this explanation for those who don't understand the
maths.

Cheers,
-- 
Guinness
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[gus]

Dear Relay Operators,

Do you want your relay to be a Tor fallback directory mirror? 
Will it have the same address and port for the next 2 years? 

Just reply to this email with your relay's fingerprint.

Important: you have until July 23 2020 to reply to this message to get
in the fallback directory mirror list.

If your relay is on the current fallback list, you don't need to do
anything.

If you're asking:

Q: What's a fallback directory mirror?

Fallback directory mirrors help Tor clients connect to the network. For
more details, see [1].

Q: Is my relay on the current list?

Search [2] and [3] for your relay fingerprint or IP address and port.
[2] is the current list of fallbacks in Tor.
[3] is used to create the next list of fallbacks.

Q: What do I need to do if my relay is on the list?

Keep the same IP address, keys, and ports. Email tor-relays if the
relay's details change.

Q: Can my relay be on the list next time?

We need fast relays that will be on the same IP address and port for 2
years. Reply to this email to get on the list, or to update the details
of your relay.

Once or twice a year, we run a script to choose about 150-200 relays
from the potential list [3] for the list in Tor [2].

Q: Why didn't my relay get on the list last time?

We check a relay's uptime, flags, and speed [4]. Sometimes, a relay
might be down when we check. That's ok, we will check it again next
time.

It's good to have some new relays on the list every release. That helps
tor clients, because blocking a changing list is harder.

cheers,
Gus

[1]
https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDirectoryMirrors
[2] 
https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc
[3]
https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list
[4]
https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log
-- 
The Tor Project
Community Team Lead
http://expyuzz4wqqyqhjn.onion/


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks

[Toralf Förster]

On 7/8/20 12:35 PM, Roger Dingledine wrote:
> * One is dividing the network into known and unknown relays, where we
> reserve some minimum fraction of attention for the known relays. Here
> the next steps are to figure out how to do load balancing properly with
> this new parameter (mainly a math problem), and to sort out the logistics
> for how to label the known relays so directory authorities can assign
> weights properly (mainly coding / operator ux).

Which boils down to "subjective" versus "objective" criterias of a weight 
distribution algorithms.

Which is fine as long as the maths behind it is public available and 
understandable.

This would enable a relay operator to verify/falsify it.


-- 
Toralf



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Please help us find a working alternative to using MaxMind's GeoLite2 databases

[fl4co]

My relay (912709C7F560CC3E9FE9604B58D598B1BFAED8C7) is not on the list. The 
Metrics pages says it’s  in the UK, but actually it’s located in Germany. I 
guess the new alternative keeps showing it wrongly in the UK.

--
fl4co

> Il giorno 7 lug 2020, alle ore 11:19, Karsten Loesing 
>  ha scritto:
> 
> On 2020-02-12 16:05, Karsten Loesing wrote:
>> Hi relay operators,
>> 
>> as you might have heard, MaxMind has changed access and use of their
>> GeoLite2 databases:
>> 
>> https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
>> 
>> This affects Onionoo and tor, and I'm trying to find a working
>> alternative on the following ticket:
>> 
>> https://trac.torproject.org/projects/tor/ticket/32978
>> 
>> Today I think I found a possible alternative by using data from another
>> provider. But before I name it here, I'd first want to find out how
>> accurate it is.
>> 
>> I tried resolving relay IP addresses of relays that have been running in
>> the past week and compared that to our existing lookups using MaxMind's
>> October database.
>> 
>> The result is that 7669 relays (93%) had the same country code and ASN.
>> 
>> I put the remaining 7% on the following wiki page:
>> 
>> https://trac.torproject.org/projects/tor/wiki/doc/MetricsGeoipComparison
>> 
>> I'd like to hear from you which data source is right and which is wrong
>> (or if both are wrong).
>> 
>> If you'd like to help, please leave comments on the ticket or in the
>> "Comment" column on that wiki page by February 19, 2020.
>> 
>> Thanks for helping!
> 
> Hello again,
> 
> I'm bumping this thread, because there's (finally) news on finding an
> alternative to MaxMind:
> 
> https://gitlab.torproject.org/tpo/metrics/trac/-/issues/32978 
> 
> 
> (Yes, you'll have to scroll down quite a bit to find the news, it's a
> long ticket.)
> 
> Can relay operators please take a look at that ticket and see if they
> find their relay in the table with different country results?
> 
> It would be neat to identify patterns there and possibly improve the
> accuracy of the new database.
> 
> Thanks for your help!
> 
> All the best,
> Karsten
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays 
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks

[Roger Dingledine]

On Tue, Jul 07, 2020 at 01:01:12AM +0200, nusenu wrote:
> > https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
> 
> thanks, I'll reply here since I (and probably others) can not reply there.

Fwiw, anybody who wants a gitlab account should just ask for one. Don't
be shy. :)

The instructions for asking are here:
https://gitlab.torproject.org/users/sign_in

> > (A) Limiting each "unverified" relay family to 0.5% doesn't by itself
> > limit the total fraction of the network that's unverified. I see a lot of
> > merit in another option, where the total (global, network-wide) influence
> > from relays we don't "know" is limited to some fraction, like 50% or 25%.
> 
> I like it (it is even stricter than what I proposed), you are basically saying
> the "known" pool should always control a fixed (or minimal?) portion - lets 
> say 75% - 
> of the entire network no matter what capacity the "unknown" pool has

Right.

> but it doesn't address the key question: 
> How do you specifically define "known" and how do you verify entities before 
> you move them to the "known" pool?

Well, the first answer is that these are two separate mechanisms, which
we can consider almost independently:

* One is dividing the network into known and unknown relays, where we
reserve some minimum fraction of attention for the known relays. Here
the next steps are to figure out how to do load balancing properly with
this new parameter (mainly a math problem), and to sort out the logistics
for how to label the known relays so directory authorities can assign
weights properly (mainly coding / operator ux).

* Two is the process we use for deciding if a relay counts as known. My
suggested first version here is that we put together a small team of Tor
core contributors to pool their knowledge about which relay operators
we've met in person or otherwise have a known social relationship with.

One nice property of "do we know you" over "do you respond to mail at
a physical address" is that the thing you're proving matters into the
future too. We meet people at relay operator meetups at CCC and Fosdem
and Tor dev meetings, and many of them are connected to their own local
hacker scenes or other local communities. Or said another way, burning
your "was I able to answer a letter at this fake address" effort is a
different tradeoff than burning your "was I able to convince a bunch of
people in my local and/or international communities that I mean well?"

I am thinking back to various informal meetings over the years at
C-base, Hacking At Random, Defcon, etc. The "social connectivity" bond
is definitely not perfect, but I think it is the best tool available to
us, and it provides some better robustness properties compared to more
faceless "proof of effort" approaches.

That said, on the surface it sure seems to limit the diversity we can
get in the network: people we haven't met in Russia or Mongolia or
wherever can still (eventually, postal service issues aside) answer a
postal letter, whereas it is harder for them to attend a CCC meetup. But
I think the answer there is that we do have a pretty good social fabric
around the world, e.g. with connections to OTF fellows, the communities
that OONI has been building, etc, so for many places around the world,
we can ask people we know there for input.

And it is valuable for other reasons to build and strengthen these
community connections -- so the incentives align.

Here the next step is to figure out the workflow for annotating relays. I
had originally imagined some sort of web-based UI where it leads me
through constructing and maintaining a list of fingerprints that I have
annotated as 'known' and a list annotated as 'unknown', and it shows
me how my lists have been doing over time, and presents me with new
not-yet-annotated relays.

But maybe a set of scripts, that I run locally, is almost as good and
much simpler to put together. Especially since, at least at first,
we are talking about a system that has on the order of ten users.

One of the central functions in those scripts would be to sort the
annotated relays by network impact (some function of consensus weight,
bandwidth carried, time in network, etc), so it's easy to identify the
not-yet-annotated ones that will mean the biggest shifts. Maybe this
ordered list is something we can teach onionoo to output, and then all the
local scripts need to do is go through each relay in the onionoo list,
look them up in the local annotations list to see if they're already
annotated, and present the user with the unannotated ones.

To avoid centralizing too far, I could imagine some process that gathers
the current annotations from the several people who are maintaining them,
and aggregates them somehow. The simplest version of aggregation is
"any relay that anybody in the group knows counts as known", but we
could imagine more complex algorithms too.

And lastly, above I said we can consider the two mechanisms "almost
independently" 

Re: [tor-relays] Please help us find a working alternative to using MaxMind's GeoLite2 databases

[Tor-abuse]

Hi Karsten,

I am the operator of relays "torturing" and "BurningMan". The right
country for torturing is Netherlands and for BurningMan Finland.


Cheers

Am 07.07.2020 um 11:19 schrieb Karsten Loesing:
> On 2020-02-12 16:05, Karsten Loesing wrote:
>> Hi relay operators,
>>
>> as you might have heard, MaxMind has changed access and use of their
>> GeoLite2 databases:
>>
>> https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
>>
>> This affects Onionoo and tor, and I'm trying to find a working
>> alternative on the following ticket:
>>
>> https://trac.torproject.org/projects/tor/ticket/32978
>>
>> Today I think I found a possible alternative by using data from another
>> provider. But before I name it here, I'd first want to find out how
>> accurate it is.
>>
>> I tried resolving relay IP addresses of relays that have been running in
>> the past week and compared that to our existing lookups using MaxMind's
>> October database.
>>
>> The result is that 7669 relays (93%) had the same country code and ASN.
>>
>> I put the remaining 7% on the following wiki page:
>>
>> https://trac.torproject.org/projects/tor/wiki/doc/MetricsGeoipComparison
>>
>> I'd like to hear from you which data source is right and which is wrong
>> (or if both are wrong).
>>
>> If you'd like to help, please leave comments on the ticket or in the
>> "Comment" column on that wiki page by February 19, 2020.
>>
>> Thanks for helping!
> Hello again,
>
> I'm bumping this thread, because there's (finally) news on finding an
> alternative to MaxMind:
>
> https://gitlab.torproject.org/tpo/metrics/trac/-/issues/32978
>
> (Yes, you'll have to scroll down quite a bit to find the news, it's a
> long ticket.)
>
> Can relay operators please take a look at that ticket and see if they
> find their relay in the table with different country results?
>
> It would be neat to identify patterns there and possibly improve the
> accuracy of the new database.
>
> Thanks for your help!
>
> All the best,
> Karsten
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks

[Guinness]

Hi all,

Le Mon, Jul 06, 2020 at 07:07:19AM -0400, Roger Dingledine écrivait :
> 
> Three highlights from that ticket that tie into this thread:
> 
> (A) Limiting each "unverified" relay family to 0.5% doesn't by itself
> limit the total fraction of the network that's unverified. I see a lot of
> merit in another option, where the total (global, network-wide) influence
> from relays we don't "know" is limited to some fraction, like 50% or 25%.

That's a great idea, but how do you say you "know" a relay ? And in this
case, I guess that this number should stay low. Here we have a case of
20% exit probability by this group of nodes, which is already huge. And
we don't necessarily know if they have as well a part of the entry
nodes.

> 
> (B) I don't know what you have in mind with verifying a physical address
> (somebody goes there in person? somebody sends a postal letter and waits
> for a response?), but I think it's trying to be a proxy for verifying
> that we trust the relay operator, and I think we should brainstorm more
> options for achieving this trust. In particular, I think "humans knowing
> humans" could provide a stronger foundation.
> 
> More generally, I think we need to very carefully consider the extra
> steps we require from relay operators (plus the work they imply for
> ourselves), and what security we get from them. Is verifying that each
> relay corresponds to some email address worth the higher barrier in
> being a relay operator? Are there other approaches that achieve a better
> balance? The internet has a lot of experience now on sybil-resistance
> ideas, especially on ones that center around proving online resources
> (and it's mostly not good news).

Two points here :
 * We should give a read to the sybil-resistance litterature around to
   see what exists and how it could be adapted to Tor. I know that a lot
   of work has already been done, but maybe some extended defenses are
   required at this point.
 * A suggestion would be to build a web-of-trust between relay
   operators, using, I don't know, PGP or something like this, and
   organize signing parties at hackers/Torproject/dev events?
   For example, I'm every year at FOSDEM in Brussels, and I attend the
   bird of feathers for Tor when it exists. However, it would prevent
   people who want to keep complete anonymity from contributing to Tor,
   which is a bad point. Maybe this lights something up in your brains?

> 
> (C) Whichever mechanism(s) we pick for assigning trust to relays,
> one gap that's been bothering me lately is that we lack the tools for
> tracking and visualizing which relays we trust, especially over time,
> and especially with the amount of network churn that the Tor network
> sees. It would be great to have an easier tool where each of us could
> assess the overall network by whichever "trust" mechanisms we pick --
> and then armed with that better intuition, we could pick the ones that
> are most ready for use now and use them to influence network weights.
> 
> 
> 
> At the same time, we need to take other approaches to reduce the impact
> and incentives for having evil relays in the network. For examples:
> 
> (1) We need to finish getting rid of v2 onion services, so we stop the
> stupid arms race with threat intelligence companies who run relays in
> order to get the HSDir flag in order to scrape legacy onion addresses.

Good point. Do you think speeding the process is possible? The deadline
is in more than one year from now, which seems a pretty long time. Or
maybe is it to synchronize with new versions of the linux/BSD
distributions?

> 
> (2) We need to get rid of http and other unauthenticated internet protocols:
> I've rebooted this ticket:
> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850
> with a suggestion of essentially disabling http connections when the
> security slider is set to 'safer' or 'safest', to see if that's usable
> enough to eventually make it the default in Tor Browser.

+1, nothing more to say.

> 
> (3) We need bandwidth measuring techniques that are more robust and
> harder to game, e.g. the design outlined in FlashFlow:
> https://arxiv.org/abs/2004.09583

I have seen that there is a proposal, and a thread on tor-dev that died
in April (lockdown maybe?), maybe we should launch again the discussions
around this technique?


-- 
Guinness
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays