Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-03-27T04:55:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/19690Tonga (Bridge Authority) Permanent Shutdown Notice2021-03-27T04:55:11ZshamrockTonga (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/legacy/trac/-/issues/33351Are bandwidth authorities concentrating too much bandwidth in one area?2020-06-13T16:04:01ZteorAre 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 (#33350) or torflow (unmaintained).https://gitlab.torproject.org/legacy/trac/-/issues/33130remove end-of-life tor versions 0.4.0.x from recommended versions to warn rel...2020-06-13T16:04:00Znusenuremove end-of-life tor versions 0.4.0.x from recommended versions to warn relay operators tor 0.4.0.x reached eol on 2020-02-02 let's remove it from the list of recommended client and server versions so operators get to see a warning on Relay Search
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor... tor 0.4.0.x reached eol on 2020-02-02 let's remove it from the list of recommended client and server versions so operators get to see a warning on Relay Search
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases
​https://consensus-health.torproject.org/#recommendedversionshttps://gitlab.torproject.org/legacy/trac/-/issues/32869remove end-of-life tor versions 0.2.9.x from recommended versions to warn rel...2020-06-13T16:04:00Znusenuremove end-of-life tor versions 0.2.9.x from recommended versions to warn relay operatorstor 0.2.9.x reached eol on 2020-01-01 let's remove it from the list of recommended client and server versions so operators get to see a warning on Relay Search
https://consensus-health.torproject.org/#recommendedversions
```
client-ver...tor 0.2.9.x reached eol on 2020-01-01 let's remove it from the list of recommended client and server versions so operators get to see a warning on Relay Search
https://consensus-health.torproject.org/#recommendedversions
```
client-versions 0.2.9.14, 0.2.9.15, 0.2.9.16, 0.2.9.17,
0.3.5.7, 0.3.5.8, 0.3.5.9, 0.4.0.5, 0.4.0.6, 0.4.1.2-alpha, 0.4.1.3-alpha, 0.4.1.4-rc, 0.4.1.5, 0.4.1.6, 0.4.1.7, 0.4.2.1-alpha, 0.4.2.2-alpha, 0.4.2.3-alpha, 0.4.2.4-rc, 0.4.2.5
server-versions 0.2.9.15, 0.2.9.16, 0.2.9.17, 0.3.5.8, 0.3.5.9, 0.4.0.5, 0.4.0.6, 0.4.1.2-alpha, 0.4.1.3-alpha, 0.4.1.4-rc, 0.4.1.5, 0.4.1.6, 0.4.1.7, 0.4.2.1-alpha, 0.4.2.2-alpha, 0.4.2.3-alpha, 0.4.2.4-rc, 0.4.2.5
```https://gitlab.torproject.org/legacy/trac/-/issues/32774Set the sendme_emit_min_version=1 consensus parameter2020-06-13T16:03:59ZteorSet 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/legacy/trac/-/issues/30533Bandwidth Unmeasured in Testing Tor Network2020-06-13T16:03:59ZTracBandwidth Unmeasured in Testing Tor NetworkI have run the Testing Tor Network based on docker, however, the bandwidth of relays in consensus is 0, and they are labeled as unmeasured.
like
```
r tor21 AXeRGqg59zZ0JOyocxlonwk84Qg zv7cbbO1TcuYfwhzA/VjeE/u9UY 2019-05-18 15:49:03 172...I have run the Testing Tor Network based on docker, however, the bandwidth of relays in consensus is 0, and they are labeled as unmeasured.
like
```
r tor21 AXeRGqg59zZ0JOyocxlonwk84Qg zv7cbbO1TcuYfwhzA/VjeE/u9UY 2019-05-18 15:49:03 172.25.0.121 5000 0
s Exit Fast Running V2Dir Valid
v Tor 0.3.5.7
pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
w Bandwidth=0 Unmeasured=1 (The bandwidth is labeled as unmeasured)
p reject 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999
```
The torrc file of my authority server is listed as following:
```
Log info file /root/log/info.log
DisableDebuggerAttachment 0
SocksPort 0
OrPort 5000
Address 172.25.0.10
DirPort 7000
AuthoritativeDirectory 1
V3AuthoritativeDirectory 1
ContactInfo auth@test.test
ExitPolicy reject *:*
ServerDNSAllowBrokenConfig 1
DirAllowPrivateAddresses 1
EnforceDistinctSubnets 0
AssumeReachable 1
AuthDirMaxServersPerAddr 0
AuthDirMaxServersPerAuthAddr 0
ClientDNSRejectInternalAddresses 0
ClientRejectInternalAddresses 0
CountPrivateBandwidth 1
ExitPolicyRejectPrivate 0
ExtendAllowPrivateAddresses 1
V3AuthVotingInterval 5 minutes
V3AuthVoteDelay 20 seconds
V3AuthDistDelay 20 seconds
MinUptimeHidServDirectoryV2 0 seconds
TestingV3AuthInitialVotingInterval 5 minutes
TestingV3AuthInitialVoteDelay 20 seconds
TestingV3AuthInitialDistDelay 20 seconds
TestingAuthDirTimeToLearnReachability 0 minutes
TestingEstimatedDescriptorPropagationTime 0 minutes
TestingClientMaxIntervalWithoutRequest 5 seconds
TestingDirConnectionMaxStall 30 seconds
TestingEnableConnBwEvent 1
TestingEnableCellStatsEvent 1
```
The version of tor is 0.3.3.8
**Trac**:
**Username**: TBD.Chenhttps://gitlab.torproject.org/legacy/trac/-/issues/29102Serialize padding state machine in consensus2020-06-13T16:03:58ZMike PerrySerialize padding state machine in consensusWe should have the ability to list padding machines in the consensus.
This might not make 041.We should have the ability to list padding machines in the consensus.
This might not make 041.https://gitlab.torproject.org/legacy/trac/-/issues/28807Ask authority operators to set `MaxAdvertisedBandwidth 0` in their torrcs2020-06-13T16:03:58ZTracAsk authority operators to set `MaxAdvertisedBandwidth 0` in their torrcsCurrently, it seems that Tor clients don't use DA nodes for construction of circuits because all DA's bandwidth is set to 20, which is a very low value. To move unneeded client traffic out of DA nodes completely, we could have some `torr...Currently, it seems that Tor clients don't use DA nodes for construction of circuits because all DA's bandwidth is set to 20, which is a very low value. To move unneeded client traffic out of DA nodes completely, we could have some `torrc` option on client's side (which disables construction of such circuits) and on DA's side (which block client's requests to use the DA as a node in its circuits). Additionally, use of DA nodes in clients circuits may be governed by some consensus values published by DA nodes.
In general, in testing Tor network with a small number of nodes, enabling this option may be undesirable, but in the main Tor network it may help DA nodes to decrease their load. Also, this explicit solution may be more clean than the current probabilistic approach which relies on a small bandwidth value set for DA nodes.
This task was originally discussed in [[comment](http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:15|another)] with teor.
**Trac**:
**Username**: wagonhttps://gitlab.torproject.org/legacy/trac/-/issues/28691dirauth longclaw network connectivity impaired2020-06-13T16:03:57Zstarlightdirauth longclaw network connectivity impairedFor quite some time the longclaw dirauth has apparently been operating with badly degraded network connectivity resulting in degraded consensus votes. Per
https://consensus-health.torproject.org/#overlap
```
Only in vote ...For quite some time the longclaw dirauth has apparently been operating with badly degraded network connectivity resulting in degraded consensus votes. Per
https://consensus-health.torproject.org/#overlap
```
Only in vote In vote and consensus Only in consensus
=============== ===================== =================
longclaw 10 Authority
3 BadExit
1 Exit 857 Exit
5 Fast 754 Fast !4857 Fast
21 Guard 453 Guard !2028 Guard
4 HSDir 476 HSDir !2952 HSDir
6472 Running !13 Running
52 Stable 5412 Stable !26 Stable
1 V2Dir 6443 V2Dir
7439 Valid
117 FallbackDir
67 Unmeasured
38 DescMismtch 0 DescMismtch
```
Of particular note longclaw marks close to 5000 relays as "not fast" compare to the consensus where other authorities see no more than about 100 as not fast w/r/t the overall consensus. A close correlation exists between "not fast" relays in longclaw's consensus and relays omitted by the SBWS scanner associated with this authority. Longclaw dirauth is not voting 2000 guard relay as such.https://gitlab.torproject.org/legacy/trac/-/issues/25447remove TROVE-2018-002 affected versions from recommended version2020-06-13T16:03:57Zcypherpunksremove TROVE-2018-002 affected versions from recommended versionarma did already remove affected versions, lets remove it on some more dir auths
affected: 0.3.2.1-alpha - 0.3.2.9, 0.3.3.1-alphaarma did already remove affected versions, lets remove it on some more dir auths
affected: 0.3.2.1-alpha - 0.3.2.9, 0.3.3.1-alphahttps://gitlab.torproject.org/legacy/trac/-/issues/25121dir auths should not recommend EOL releases 0.3.0.13, 0.3.0.142020-06-13T16:03:56Zcypherpunksdir auths should not recommend EOL releases 0.3.0.13, 0.3.0.14Lets remove 0.3.0.13, 0.3.0.14 from
https://consensus-health.torproject.org/#recommendedversions
they reached eol:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleasesLets remove 0.3.0.13, 0.3.0.14 from
https://consensus-health.torproject.org/#recommendedversions
they reached eol:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleaseshttps://gitlab.torproject.org/legacy/trac/-/issues/25096Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?2020-06-13T16:03:56ZRoger 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 (#9574).
TAP handshakes are used b...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 (#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/legacy/trac/-/issues/24768Increase nf_conntimeout_clients to 5 hours2020-06-13T16:03:55ZteorIncrease nf_conntimeout_clients to 5 hoursMaybe we should experiment with making the client circuit timeout higher.
It defaults to 30 minutes. It's new in 0.3.1.
```
+#define CIRCTIMEOUT_CLIENTS_DFLT (30*60) // 30 minutes
+#define CIRCTIMEOUT_CLIENTS_MIN 60
+#define CIRCTIMEOU...Maybe we should experiment with making the client circuit timeout higher.
It defaults to 30 minutes. It's new in 0.3.1.
```
+#define CIRCTIMEOUT_CLIENTS_DFLT (30*60) // 30 minutes
+#define CIRCTIMEOUT_CLIENTS_MIN 60
+#define CIRCTIMEOUT_CLIENTS_MAX (24*60*60) // 24 hours
+ timeout = networkstatus_get_param(NULL, "nf_conntimeout_clients",
+ CIRCTIMEOUT_CLIENTS_DFLT,
+ CIRCTIMEOUT_CLIENTS_MIN,
+ CIRCTIMEOUT_CLIENTS_MAX);
```https://gitlab.torproject.org/legacy/trac/-/issues/24716Try cranking up cbttestfreq consensus param, to see if it helps the current o...2020-06-13T16:03:55ZRoger 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/legacy/trac/-/issues/24496Remove old Tor versions from recommended server versions2020-06-13T16:03:48ZcypherpunksRemove old Tor versions from recommended server versionsImportant updates got released lately, recommended versions should be updated accordingly.
only the following tor versions should be recommended:
0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9 and 0.3.2.6-alpha
motivation:
- #21394 D...Important updates got released lately, recommended versions should be updated accordingly.
only the following tor versions should be recommended:
0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9 and 0.3.2.6-alpha
motivation:
- #21394 DNS issue for exits
http://arthuredelstein.net/exits
Arthur and I are trying to reach out to affected operators but some have no contactInfo, increasing the recommended versions would at least show them some information in their log entries.
https://trac.torproject.org/projects/tor/wiki/TROVE
- #24244
- #24245
- #24246
- #24333
- #24430
debian packages via deb.tpo are available, lets make this change once
0.3.1.9 is available on FreeBSD repos (I'll post to this ticket when that happens).https://gitlab.torproject.org/legacy/trac/-/issues/24485Maybe found a Bad exit?2020-06-13T16:03:48ZcypherpunksMaybe found a Bad exit?Liberia 197.231.221.211 with https://bugzilla.mozilla.org/ always returns a "Secure Connection Failed"
(Sorry for putting it in the bugtracker, I don't know of any email service that allows Tor users and I don't think disposable mail se...Liberia 197.231.221.211 with https://bugzilla.mozilla.org/ always returns a "Secure Connection Failed"
(Sorry for putting it in the bugtracker, I don't know of any email service that allows Tor users and I don't think disposable mail service would be accepted in the bad-tor relays mail list)https://gitlab.torproject.org/legacy/trac/-/issues/24264Enable IPv6 reachability testing for the Bridge Authority2020-06-13T16:03:47ZIsis 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/legacy/trac/-/issues/24258dir auths should set nf_conntimeout_clients param?2020-06-13T16:03:46ZRoger Dingledinedir auths should set nf_conntimeout_clients param?I found some more params in the code since we last set params.
We should grep for networkstatus_get_param() and figure out what params are new and if we want to set any of them in the consensus preemptively for robustness.I found some more params in the code since we last set params.
We should grep for networkstatus_get_param() and figure out what params are new and if we want to set any of them in the consensus preemptively for robustness.https://gitlab.torproject.org/legacy/trac/-/issues/24227remove v0.3.2.x before 0.3.2.4-alpha from recommended server versions2020-06-13T16:03:45Zcypherpunksremove v0.3.2.x before 0.3.2.4-alpha from recommended server versionsreason: #21394
stable releases are also affected but there is no fixed release out yetreason: #21394
stable releases are also affected but there is no fixed release out yethttps://gitlab.torproject.org/legacy/trac/-/issues/23031lets remove tor versions 0.2.[467] from 'recommended version' after their EOL...2020-06-13T16:03:45Zcypherpunkslets remove tor versions 0.2.[467] from 'recommended version' after their EOL date (2017-08-01)we should not recommend versions that reached their eol date
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleaseswe should not recommend versions that reached their eol date
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases