Hello everyone, during the 36c3 we organized a Tor Assembly, same as in 2017/2018. The 36c3 is the annual congress of the Germany CCC (Chaos Computer Club), which is a gathering of 17.000 people of the hacking community. I has grown a lot and people from all over the world are attending.
We also had two sessions, one was a relay operator meetup with FAQ and a presentation [1] of "Foundation of Applied Privacy" about their Exits. The other session was a Tor organizations meetup. During the organizations meetup some notes were taken and it was agreed to share those afterwards.
[1] https://appliedprivacy.net/presentations/
The following topics were discussed:
+ Concentration of Tor exit capacity in unique entities, how much of the Tor (exit) capacity should be in control of one group or person?
++ This is a recurring discussion, various people have suggested limits between 5% and 10% exit probability.
++ Frënn vun der Ënn are working on a "Tor Organization Code of Conduct" including such a self-limitation - This was only mentioned by some participants and is not first hand information.
+ Professionalization of operation and administration, challenges in finding/keeping volunteers.
++ One organization is running on "grown" infrastructure that is administrated by Perl scripts, which new volunteers are having difficulties working with.
++ Sharing documentation/code used by various organizations might be a solution, this has also been asked for at the Tor Relay Operator Meetup.
+ Why are people scared of abuse? What problem does a hosting provider face if abuse happens/is not stopped?
++ At least for most servers rented from ISPs, if you don't react to abuse email in a timely manner, they will disconnect you.
++ On a higher level, there seems to be a risk for ASNs with too much unchecked abuse.
+ Procurement of hardware
++ One organization mentioned CPU load issues if they allow port 22 exit traffic. Better hardware might help them.
++ If you can donate relatively modern server hardware to Tor organization, please consider mentioning this on tor-relays mailing list.
+ Handing over the administration of Torservers.net has not progressed very much.
++ Original post: https://lists.torproject.org/pipermail/tor-relays/2019-May/017269.html
++ One problem could be a lack of information about the type and amount of work that needs to be done.
++ Handling press inquiries has been taken over by a group of other organizations, seems to be working well.
+ IPv6
++ Some major Tor exit operator might loose their IPv4 space within the next 2-3 years, which makes progress in the IPv6 area crucial for them to continue contributing to the network.
++ The Tor Project got IPv6 funding from RIPE NCC, but in addition to the software portion (Tor Project responsibility) also operators need to take action and ensure they have IPv6 connectivity enabled on their systems.
+ BGP Routing Security
++ BGPalerter is an easy to use tool to monitor your ASN for hijacking attempts and visibility issues nitor your ASN for hijacking attempts and visibility issues https://github.com/nttgin/BGPalerter
+ Future meetings
++ Some organizations wish to be invited to the Tor meetings. People of some organizations attend the meetings aready through other means.
The meetup took 90 minutes, in the end it was decided to organize a meetup like this each year. Quarterly mumble meetings are to be held.
Some of the organizations present (in alphabetical order) were:
Artikel10 - https://artikel10.org/ Artikel 5 e.V. - https://www.artikel5ev.de/ Digitalcourage - https://digitalcourage.de/en Digitale Gesellschaft - https://www.digitale-gesellschaft.ch/ Emerald Onion - https://emeraldonion.org/meraldonion.org/meraldonion.org/meraldonion.org/mer... F3 Netze - https://f3netze.de/ Foundation for Applied Privacy - https://applied-privacy.net/ Nos Oignons - https://nos-oignons.net/ Zwiebelfreunde - https://www.zwiebelfreunde.de/
This text was composed in a pad by various people, the license of the text is CC-BY-SA 3.0, original text can be found here: https://cryptpad.fr/pad/#/2/pad/edit/eMjLydN6sIQSMbHwNwzIUHDL/
// End of protocol
I hope there is no information missing, I shared the pad and some people were working on the text in the last 3 days, please feel free to discuss the topics mentioned and also feel free to add information missing.
Hi
Thanks you for the very nice protocol.
Am Freitag, den 03.01.2020, 15:45 +0100 schrieb ml- torrelays@artikel5ev.de:
- Concentration of Tor exit capacity in unique entities, how much of
the Tor (exit) capacity should be in control of one group or person?
++ This is a recurring discussion, various people have suggested limits between 5% and 10% exit probability.
I think it's worth to mention, that some peopled stated that they don't know if 15% or even more would be a problem.
There was also the hint, that the biggest players are playing very fair by telling people about their correlations via the family setup. At least it looks like that. Someone stated that there is a lot correlated exit capacity without family setup.
Besides the meeting.. I never heard a real technical reason to avoid high concentration of Tor exit capacity. But on the other side, I can see how the Tor network consumes all the exit capacity. So it looks like the demand is high.
Maybe it would be a good idea to adapt some filters etc, to reduce the bulk and scan traffic. E.g. port 22 has obviously a such high misuse rate, that the traffic vs packet rate is too evil for our cpu capacity.
Sure it is nice to help scientist to scan the networks, bus .. realy .. don't they have enough capacities at the universities?
Tim
I never heard a real technical reason to avoid high concentration of Tor exit capacity.
Let me give you a few examples why a distributed network is in some ways more resilient to attacks and harder to observe than a centralized.
Observability
If all traffic leaves the tor network at a single or very few places, surveillance becomes a lot easier and cheaper when compared to a network that is distributed and has many exit locations.
Resiliency against outages
If all capacity is concentrated around just a few locations, local issues/outages have a bigger impact on the overall availability and capacity of the network.
Resiliency against software vulnerabilities
A single operator tends to setup their systems in a relatively similar manner. Most of its relays will use the same OS, OS version, SSL library, tor version, hardware architecture and have a similar good or bad patch level. In such an environment it is more likely that a single vulnerability affects large portions when compared to a diverse ecosystem. A homogeneous ecosystem also reduces the cost for exploit development.
Resiliency against security breaches
If an hypothetical operator controlling 1/2 of the network gets compromised the impact is a lot bigger than if they were to run 1%. The incentive for an attacker to compromise an operator running 50% of the network is also a lot higher than attacking an operator of 1%.
Risk of detection The risk of detection is likely higher for an attacker that compromises multiple organizations compared to a single victim.
Cost of attacks Compromising all relays operated by a single entity is likely cheaper than compromising all relays run by multiple independent organizations.
Performing a hijacking attack against a single prefix is probably easier than successfully hijacking multiple independent prefixes with different upstream providers concurrently and harder to remain undetected.
A DDoS attack against a single AS is likely cheaper than against many targets at the same time.
There are also non-technical (organizational and legal) reasons why having a distributed network capacity is beneficial to the tor network.
Legally attacking many organizations is more expensive than a single one. If a single operator no longer has the financial capacity or motivation the removal of their relays should not have a existential impact on the network. If the policy of a hoster changes from 'tor relays allowed' to 'tor relays forbidden' than we better not run all our capacity at a single hoster.
In short, you don't want to make the tor network depend on 1-2 or 10 but many. So if a few operators disappear the network remains functional and available and is generally harder to attack.
kind regards, nusenu
Hi nusenu
Thanks for your explanation. You are right in all points. But they are a bit of theoretical, because we don't have big choice here. Further I don't think a big exit is the opposite of our goals, it's just the beginning.
Theoretical
So what can we do to achieve the ideal distributed network? Throttle all exits to the slowest exit, to get the best diversity? It would be awesome if we only have exit families with max 0.05% overall capacity (with each multiple gigabits). But currently we need only 5GBit/s bandwidth and 2 office computers for ~7%. That's ridiculous, it's year 2020!
Diversity
Shouldn't the tor software handle the diversity? So what if an intelligence adds an exits with ~100 GBit/s? Will it gain all exit traffic? And if so, is that a real problem for a tor user (which uses end to end authentication etc)? And if so, why don't we change the software?
Am Samstag, den 04.01.2020, 11:44 +0000 schrieb nusenu:
I never heard a real technical reason to avoid high
concentration of Tor exit capacity.
In short, you don't want to make the tor network depend on 1-2 or 10 but many. So if a few operators disappear the network remains functional and available and is generally harder to attack.
Maybe my point wasn't clear.. my mistake.
While the tor network currently depends on some high exit capacity families, it's not the mistake of them. Instead it's the mistake of all others which don't provide exit capacity.
The right way besides throttling
The only right solution can be to encourage others to add more exit capacity. So instead to throttle the available resources and blame the people behind them, we should say a big "thank you" to all people and orgs that provide us with exit resources. Besides the resources, these providers handle all the troubles with police and other annoying things and that is the really hard work of an exit relay.
We need all exits, whether high or small capacity. Don't we?
Tim
Thanks for your explanation. You are right in all points. But they are a bit of theoretical, because we don't have big choice here. Further I don't think a big exit is the opposite of our goals, it's just the beginning.
I believe they are less theoretical than one might think.
One practical example that comes to mind is when the Tor network was affected by the Debian openssl bug in 2014 or the removal of outdated relays in October 2019.
Shouldn't the tor software handle the diversity?
Yes I believe it should, but I'm not sure about the exact definition of 'handle'.
My understanding is that you are looking for an authoritative answer to the question:
What is the acceptable upper limit of a relay operator in terms of fraction of the Tor network capacity (cw fraction) or an authoritative answer that there is no such limit.
Actually I was always looking forward to see someone test this practically by adding capacity (in a transparent and responsible way) since I doubt there will be a public authoritative answer that is more specific than what we have already on the record and that gets actually enforced.
On a side note: Should anyone be worried about big publicly declared operators than I would recommend to turn your eye towards less publicly declared Tor capacity that might be run with less noble intentions.
Having big fractions of the Tor network that is actually attributable to some extend will actually be beneficial to another side project I'm interested in to reduce the risk of the increasing fraction of malicious or at least rather dodgy relay capacity.
nusenu:
Actually I was always looking forward to see someone test this practically by adding capacity (in a transparent and responsible way)
that was faster than expected.. Say hi to >250 new exits :)
Let's see how long they stay ;)
So what can we do to achieve the ideal distributed network? Throttle all (nodes) to the slowest... to get the best diversity? We need all (nodes), whether high or small capacity. Don't we?
Tor is a form of gravity well. If the cloud is not saturated, adding more nodes increases odds of traffic analysis. Among other things, tor's utilization falloff curve should probably not give many users and use cases much comfy feels. Tor's design doesn't provide a way to distributively utilize excess nodes safely, it cannot, so it tries to game and manage that as best it can. Such global throttle could help, but access to throughput will disappear, and it's still subject to same class of analysis. Tor's design can't really do much here while still being called tor. Look elsewhere for other designs.
Hello everyone,
we (Frënn vun der Ënn) are working on a "Tor Organization Code of Conduct" .
In the next weeks you will get further information.
Best regards
Chrëscht
Internation Ambassador
Frënn vun der Ënn A.S.B.L.
Am 03.01.20 um 15:45 schrieb ml-torrelays@artikel5ev.de:
Hello everyone, during the 36c3 we organized a Tor Assembly, same as in 2017/2018. The 36c3 is the annual congress of the Germany CCC (Chaos Computer Club), which is a gathering of 17.000 people of the hacking community. I has grown a lot and people from all over the world are attending.
We also had two sessions, one was a relay operator meetup with FAQ and a presentation [1] of "Foundation of Applied Privacy" about their Exits. The other session was a Tor organizations meetup. During the organizations meetup some notes were taken and it was agreed to share those afterwards.
[1] https://appliedprivacy.net/presentations/
The following topics were discussed:
- Concentration of Tor exit capacity in unique entities, how much of the
Tor (exit) capacity should be in control of one group or person?
++ This is a recurring discussion, various people have suggested limits between 5% and 10% exit probability.
++ Frënn vun der Ënn are working on a "Tor Organization Code of Conduct" including such a self-limitation - This was only mentioned by some participants and is not first hand information.
- Professionalization of operation and administration, challenges in
finding/keeping volunteers.
++ One organization is running on "grown" infrastructure that is administrated by Perl scripts, which new volunteers are having difficulties working with.
++ Sharing documentation/code used by various organizations might be a solution, this has also been asked for at the Tor Relay Operator Meetup.
- Why are people scared of abuse? What problem does a hosting provider
face if abuse happens/is not stopped?
++ At least for most servers rented from ISPs, if you don't react to abuse email in a timely manner, they will disconnect you.
++ On a higher level, there seems to be a risk for ASNs with too much unchecked abuse.
- Procurement of hardware
++ One organization mentioned CPU load issues if they allow port 22 exit traffic. Better hardware might help them.
++ If you can donate relatively modern server hardware to Tor organization, please consider mentioning this on tor-relays mailing list.
- Handing over the administration of Torservers.net has not progressed
very much.
++ Original post: https://lists.torproject.org/pipermail/tor-relays/2019-May/017269.html
++ One problem could be a lack of information about the type and amount of work that needs to be done.
++ Handling press inquiries has been taken over by a group of other organizations, seems to be working well.
- IPv6
++ Some major Tor exit operator might loose their IPv4 space within the next 2-3 years, which makes progress in the IPv6 area crucial for them to continue contributing to the network.
++ The Tor Project got IPv6 funding from RIPE NCC, but in addition to the software portion (Tor Project responsibility) also operators need to take action and ensure they have IPv6 connectivity enabled on their systems.
- BGP Routing Security
++ BGPalerter is an easy to use tool to monitor your ASN for hijacking attempts and visibility issues nitor your ASN for hijacking attempts and visibility issues https://github.com/nttgin/BGPalerter
- Future meetings
++ Some organizations wish to be invited to the Tor meetings. People of some organizations attend the meetings aready through other means.
The meetup took 90 minutes, in the end it was decided to organize a meetup like this each year. Quarterly mumble meetings are to be held.
Some of the organizations present (in alphabetical order) were:
Artikel10 - https://artikel10.org/ Artikel 5 e.V. - https://www.artikel5ev.de/ Digitalcourage - https://digitalcourage.de/en Digitale Gesellschaft - https://www.digitale-gesellschaft.ch/ Emerald Onion - https://emeraldonion.org/meraldonion.org/meraldonion.org/meraldonion.org/mer... F3 Netze - https://f3netze.de/ Foundation for Applied Privacy - https://applied-privacy.net/ Nos Oignons - https://nos-oignons.net/ Zwiebelfreunde - https://www.zwiebelfreunde.de/
This text was composed in a pad by various people, the license of the text is CC-BY-SA 3.0, original text can be found here: https://cryptpad.fr/pad/#/2/pad/edit/eMjLydN6sIQSMbHwNwzIUHDL/
// End of protocol
I hope there is no information missing, I shared the pad and some people were working on the text in the last 3 days, please feel free to discuss the topics mentioned and also feel free to add information missing.
Christophe Kemp:
we (Frënn vun der Ënn) are working on a "Tor Organization Code of Conduct" .
Due to some re-occurring issues I'm also interested in putting together some guidelines.
I'd like to see this as a general as possible and have all relays in scope, I don't think it makes sense to limit it to "Tor Organizations".
tor-relays@lists.torproject.org