Directory Authorities issueshttps://gitlab.torproject.org/tpo/core/dirauth/-/issues2022-02-07T19:22:52Zhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/33351Are bandwidth authorities concentrating too much bandwidth in one area?2022-02-07T19:22:52ZteorAre bandwidth authorities concentrating too much bandwidth in one area?Are there too many bandwidth scanners and servers in the same area (western Europe / eastern North America) ?
Are the bandwidth scanners and servers too close together?
(If they are in the same data center, then any 2 relays that are in...Are there too many bandwidth scanners and servers in the same area (western Europe / eastern North America) ?
Are the bandwidth scanners and servers too close together?
(If they are in the same data center, then any 2 relays that are in the same data center will get unrealistic results.)
There could also be specific bugs in sbws (legacy/trac#33350) or torflow (unmaintained).https://gitlab.torproject.org/tpo/core/dirauth/-/issues/32774Set the sendme_emit_min_version=1 consensus parameter2020-06-27T14:11:26ZteorSet the sendme_emit_min_version=1 consensus parameterWe decided to set the sendme_emit_min_version=1 consensus parameter when 0.4.1 was released:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/ReleaseParameters#a0.4.1stableshippedinTorBrowser
But it isn't currently se...We decided to set the sendme_emit_min_version=1 consensus parameter when 0.4.1 was released:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/ReleaseParameters#a0.4.1stableshippedinTorBrowser
But it isn't currently set in the consensus:
https://consensus-health.torproject.org/#consensusparamsDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/25096Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?2021-11-05T13:05:01ZRoger DingledineBump up NumNTorsPerTAP to squeeze out v2 onion service traffic?Right now the consensus is voting NumNTorsPerTAP=100, i.e. relays will handle one tap handshake for every 100 ntor handshakes they handle. We put this feature into place during the 2013 botnet overload (legacy/trac#9574).
TAP handshakes...Right now the consensus is voting NumNTorsPerTAP=100, i.e. relays will handle one tap handshake for every 100 ntor handshakes they handle. We put this feature into place during the 2013 botnet overload (legacy/trac#9574).
TAP handshakes are used by obsolete clients (we don't know how many of these remain, but I think it might be quite few), and for v2 onion service clients reaching intro points, and for v2 onion services reaching rendezvous points.
With the recent overload that has to do with v2 onion services, the TAP frequency has gone up, e.g.
```
Jan 30 11:46:23.580 [notice] Circuit handshake stats since last time: 1350439/1350439 TAP, 68743431/68743431 NTor.
Jan 30 17:46:23.592 [notice] Circuit handshake stats since last time: 1183340/1183340 TAP, 71590118/71590118 NTor.
Jan 30 23:50:19.525 [notice] Circuit handshake stats since last time: 1069004/1069004 TAP, 72357977/72357977 NTor.
```
It's still low compared to the NTor frequency, but 1M TAP handshakes per 6 hours is 46 second per second to my relay.
(Also note that these log messages don't include stats from client connections, because we wanted to leave those out to be cautious about client privacy.)
The key realization here is that we can squeeze down v2 onion service usage, by squeezing down the prioritization for TAP handshakes.
Now, on my relay above, I'm able to handle all of both kinds, so changing the ratio will just change which cells get answered first -- and given that ntor cells are so much cheaper to answer than tap cells, there could be a moderate win there.
But for relays that can't handle the load, if they're similarly getting 1:70 ratios, we could potentially have a much bigger impact by cranking up the balance. If we got to the point where most of the ntors are handled and some of the taps are left unhandled, that seems like a fine balance.
So: good idea, bad idea? And if good idea, what's a good new number? 500? 1000?https://gitlab.torproject.org/tpo/core/dirauth/-/issues/24716Try cranking up cbttestfreq consensus param, to see if it helps the current o...2020-06-27T14:11:27ZRoger DingledineTry cranking up cbttestfreq consensus param, to see if it helps the current overloadIn Tor 0.3.1.1-alpha, commit d5a151a, we switched:
```
-#define CBT_DEFAULT_TEST_FREQUENCY 60
+#define CBT_DEFAULT_TEST_FREQUENCY 10
```
And on May 20 2017 the dir auths set the cbttestfreq consensus param to 10 as well.
Right now the ...In Tor 0.3.1.1-alpha, commit d5a151a, we switched:
```
-#define CBT_DEFAULT_TEST_FREQUENCY 60
+#define CBT_DEFAULT_TEST_FREQUENCY 10
```
And on May 20 2017 the dir auths set the cbttestfreq consensus param to 10 as well.
Right now the network is overloaded with create cells, from the millions of new clients that showed up in the past weeks.
Hypothesis 1: most of these clients are in learning mode much of the time, so 5 million clients * 10 seconds = 500k new create requests per second launched at the network, which contributes to the overload.
Hypothesis 2: some of these clients have learned quite low timeouts, causing them to generate many circuits which they then almost immediately cancel, but not enough of their circuits fail that they back away from their learned value.
Hypothesis 3: the clients are stuck in a sad loop where they learn a low cbt value, generate circuits for a while that mostly time out, eventually they give up on their cbt value, then they generate a circuit every 10s until they re-learn a low cbt value, and they cycle.
The experiment here (set cbttestfreq to 600 seconds temporarily) should help us test these hypotheses. For 1, we will immediately reduce the load of new circuits. For 2, this will help more slowly, because we'll have to wait for each client to hit a situation where 90%+ of its circuit attempts are being timed out, but in theory clients will slowly shift from having a too-aggressive cbt, back into learning mode. And for 3, we'll push most clients to the "learning, but very slowly" phase of their sad loop.
We can use the notice-level heartbeat messages in relay logs, to discover whether the total number of create cells goes down dramatically. If it does, win, we confirmed one or more of these hypotheses, and we can make a plan from there. If it doesn't, also win, we know we need to look elsewhere.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/24264Enable IPv6 reachability testing for the Bridge Authority2020-06-27T14:11:28ZIsis LovecruftEnable IPv6 reachability testing for the Bridge AuthorityWe'll need to set `AuthDirHasIPv6Connectivity 1`.We'll need to set `AuthDirHasIPv6Connectivity 1`.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/22306Dir auths should consider changing their cbttestfreq param vote2020-06-27T14:11:28ZRoger DingledineDir auths should consider changing their cbttestfreq param voteTor 0.3.1.1-alpha will reduce the default for the cbttestfreq consensus parameter from 60 to 10 (see legacy/trac#17592).
Currently the directory authorities vote 60 for it, for robustness against a small number of dir auths choosing a h...Tor 0.3.1.1-alpha will reduce the default for the cbttestfreq consensus parameter from 60 to 10 (see legacy/trac#17592).
Currently the directory authorities vote 60 for it, for robustness against a small number of dir auths choosing a harmful number.
We should consider changing our param votes to 10, to match the upcoming code.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/21915Add a new directory authority: Nicholas Merrill2020-06-27T14:11:29ZDavid Gouletdgoulet@torproject.orgAdd a new directory authority: Nicholas MerrillThis ticket is to add Nicholas Merrill (legacy/trac#21914) relay as a new directory authority. At this time, his candidate relay has been running in the test network for many months and Nick is working at transitioning it to the real net...This ticket is to add Nicholas Merrill (legacy/trac#21914) relay as a new directory authority. At this time, his candidate relay has been running in the test network for many months and Nick is working at transitioning it to the real network.
We've requested of Nick to also run a bandwidth authority.
Once Nick has completed the setup, he will be adding the needed information on this ticket so we can then create a `DirServer` line that current dirauth can add to their configuration.
Once that is complete and working, a `config.c` patch will be provided (GPG signed) and hopefully confirmed by others.
Putting in the 031 milestone and we'll handle the backport in time.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/19690Tonga (Bridge Authority) Permanent Shutdown Notice2020-06-27T14:11:30ZshamrockTonga (Bridge Authority) Permanent Shutdown NoticeDear friends,
Given recent events, it is no longer appropriate for me to materially contribute to the Tor Project either financially, as I have so generously throughout the years, nor by providing computing resources. This decision does...Dear friends,
Given recent events, it is no longer appropriate for me to materially contribute to the Tor Project either financially, as I have so generously throughout the years, nor by providing computing resources. This decision does not come lightly; I probably ran one of the first five nodes in the system and my involvement with Tor predates it being called "Tor" by many years.
Nonetheless, I feel that I have no reasonable choice left within the bounds of ethics, but to announce the discontinuation of all Tor-related services hosted on every system under my control.
Most notably, this includes the Tor node "Tonga", the "Bridge Authority", which I recognize is rather pivotal to the network
Tonga will be permanently shut down and all associated crytographic keys destroyed on 2016-08-31. This should give the Tor developers ample time to stand up a substitute. I will terminate the chron job we set up so many years ago at that time that copies over the descriptors.
In addition to Tonga, I will shut down a number of fast Tor relays, but the directory authorities should detect that shutdown quickly and no separate notice is needed here.
I wish the Tor Project nothing but the best moving forward through those difficult times,
--LuckyTor: 0.2.8.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/19279Another EXIT node tempering HTTP webpage2020-06-27T14:11:30ZTracAnother EXIT node tempering HTTP webpageSome exit node serve this.
Is OONI(bad tor node detector) really scanning exit nodes?
(P.S. Stop detecting "http" link as spam. I am not a cypherpunks(anonymous))
----------------------------
<!DOCTYPE html>
<html>
<head>
<meta charset=...Some exit node serve this.
Is OONI(bad tor node detector) really scanning exit nodes?
(P.S. Stop detecting "http" link as spam. I am not a cypherpunks(anonymous))
----------------------------
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name=viewport content="width=device-width, initial-scale=1">
<link rel="canonical" href="https www.google.com/">
<title>Welcome! Google Official Site</title>
</head>
<body>
<h1>Welcome! Google Official Site</h1>
<p>
Google’s mission is to organize the world’s information and make it universally accessible and useful.
</p>
<h2>Focus on the user and all else will follow</h2>
<p>
Since the beginning, we’ve focused on providing the best user experience possible. Whether we’re designing a new Internet browser or a new tweak to the look of the homepage, we take great care to ensure that they will ultimately serve you, rather than our own internal goal or bottom line.
</p>
<h2>News from Google</h2>
<p>
Read up on our latest news, browse our blog directory, or choose to follow a number of Google+ pages for updates on various products and initiatives.
</p>
<h2>Google careers</h2>
<p>
Ever wondered what life at Google looks like or what benefits you might expect as a Googler? Search for a job at Google or check out one of our locations worldwide.
</p>
</body>
</html>
**Trac**:
**Username**: ikurua22https://gitlab.torproject.org/tpo/core/dirauth/-/issues/19117TOR Exit Node Blacklisted2020-06-27T14:11:30ZTracTOR Exit Node BlacklistedI don't know where the best place for this is, so if this isn't it, could you point me in the right direction? My TOR relay has been marked as a bad exit. I'd like to figure out why, and correct the issue so my relay can be used for exit...I don't know where the best place for this is, so if this isn't it, could you point me in the right direction? My TOR relay has been marked as a bad exit. I'd like to figure out why, and correct the issue so my relay can be used for exit traffic again - TOR is the primary reason that machine exists. Its alias is "tylerlockedotorg". Thanks.
**Trac**:
**Username**: arakielhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/17813IPv6 address for urras2020-06-27T14:11:31ZteorIPv6 address for urrasI'm trying to get Tor clients to bootstrap over IPv6 (legacy/trac#17281).
This requires adding directory authorities' IPv6 addresses to the tor source code.
urras has an IPv6 address (legacy/trac#17298), but it isn't being displayed in ...I'm trying to get Tor clients to bootstrap over IPv6 (legacy/trac#17281).
This requires adding directory authorities' IPv6 addresses to the tor source code.
urras has an IPv6 address (legacy/trac#17298), but it isn't being displayed in Globe at the moment.
Can you let me know if there's an IPv6 address for urras you want me to add, or if I should leave it out for the moment?