The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-19T13:14:07Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/39test bridges every hour2024-03-19T13:14:07Zmeskiomeskio@torproject.orgtest bridges every hourWe want to use bridgestrap results to know if a bridge is running, instead of using the 'Running' flag (https://gitlab.torproject.org/tpo/network-health/team/-/issues/318). For that bridgstrap will need to update it's collector file ever...We want to use bridgestrap results to know if a bridge is running, instead of using the 'Running' flag (https://gitlab.torproject.org/tpo/network-health/team/-/issues/318). For that bridgstrap will need to update it's collector file every hour, currently bridgestrap tests bridges every 18h and publishes the collector file every day.
Is bridgestrap able to test all bridges every hour? Or do we need to consider other options (https://gitlab.torproject.org/tpo/core/arti/-/issues/717)?meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/177export bridge ratio and acceptance in the collector metrics2024-03-19T08:48:07Zmeskiomeskio@torproject.orgexport bridge ratio and acceptance in the collector metricsLet's add a field with the bridge ratio status into the collector metrics.Let's add a field with the bridge ratio status into the collector metrics.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40687dirauth: Change dizum IP address2024-03-11T10:13:10ZDavid Gouletdgoulet@torproject.orgdirauth: Change dizum IP addressWe had a request from dizum's operator on the dirauth list to change its IP going to another AS he controls.
Change is from `45.66.33.45` in `AS47482 (AS-SPECTRE)` -> `45.66.35.11` in `AS61125 (AS-SABOTAGE)`We had a request from dizum's operator on the dirauth list to change its IP going to another AS he controls.
Change is from `45.66.33.45` in `AS47482 (AS-SPECTRE)` -> `45.66.35.11` in `AS61125 (AS-SABOTAGE)`Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40816metrics: New circuit related metrics relay side2024-01-31T07:14:18ZDavid Gouletdgoulet@torproject.orgmetrics: New circuit related metrics relay sideThis is tied to sponsor 112 with https://gitlab.torproject.org/tpo/network-health/team/-/issues/299.
We need to implement these:
- Number of circuit collapsing as in DESTROY coming from the opposite direction.
- Circuit being closed du...This is tied to sponsor 112 with https://gitlab.torproject.org/tpo/network-health/team/-/issues/299.
We need to implement these:
- Number of circuit collapsing as in DESTROY coming from the opposite direction.
- Circuit being closed due to protocol violation.
- Anything around drop cells. A rate, what type, etc...
Basically, keep counters of those events and expose them on the `MetricsPort`.Tor: 0.4.9.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40680DoS: Block client IPs exceeding circuit max queue size2023-12-31T20:22:43ZDavid Gouletdgoulet@torproject.orgDoS: Block client IPs exceeding circuit max queue sizeIdea is that organically, this should not happen because of congestion control and so if a client connection is reaching that state on a Guard, we want to add them to the anti-DoS subsystem so they are denied to create circuit for `DoSCi...Idea is that organically, this should not happen because of congestion control and so if a client connection is reaching that state on a Guard, we want to add them to the anti-DoS subsystem so they are denied to create circuit for `DoSCircuitCreationDefenseTimePeriod`.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41400obsolete package on weather-01: python3-flask-assets2023-12-05T16:51:36Zanarcatobsolete package on weather-01: python3-flask-assetsSince we upgraded weather-01 to Debian bookworm, the `python3-flask-assets` package is marked as "obsolete". It was indeed removed before the stable release, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000555
@sarthikg @gk : ...Since we upgraded weather-01 to Debian bookworm, the `python3-flask-assets` package is marked as "obsolete". It was indeed removed before the stable release, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000555
@sarthikg @gk : is that package still required by weather-01? if so, could you vendor the dependency and manage it yourself so we can purge the unmaintained package?
thanks!Debian 12 bookworm upgradeanarcatanarcathttps://gitlab.torproject.org/tpo/core/tor/-/issues/40760Reject relays running Tor 0.4.5.x2023-12-03T18:23:06ZnonameformeeReject relays running Tor 0.4.5.xSimilar to previous tickets (e.g. #40480, #40559 and #40664) tor should reject EOL versions at the directory authority level.
This time the 0.4.5 series is concerned, as this version reached EOL on 15th of February 2023 as per https://g...Similar to previous tickets (e.g. #40480, #40559 and #40664) tor should reject EOL versions at the directory authority level.
This time the 0.4.5 series is concerned, as this version reached EOL on 15th of February 2023 as per https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases (as read 2023-02-16T20:00:00Z).https://gitlab.torproject.org/tpo/core/tor/-/issues/40664Reject relays running Tor 0.4.6.x2023-12-03T18:23:06ZGeorg KoppenReject relays running Tor 0.4.6.xSimilar to previous tickets (e.g. #40480 and #40559) we should reject EOL versions at the directory authority level. This time the 0.4.6 series is concerned.
We started the whole process this week and are about to contact all relay oper...Similar to previous tickets (e.g. #40480 and #40559) we should reject EOL versions at the directory authority level. This time the 0.4.6 series is concerned.
We started the whole process this week and are about to contact all relay operators with a valid contact information. Additionally, we sent an announcement to [tor-relays@](https://lists.torproject.org/pipermail/tor-relays/2022-August/020765.html).Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40559Reject relays running Tor 0.3.5.x2023-12-03T18:23:05ZGeorg KoppenReject relays running Tor 0.3.5.xSimilar to #31549, #32672, #34357, and #40480 we should reject EOL versions at the directory authority level. This time version 0.3.5 is concerned.
We started the whole process this week and are about to contact all relay operators with...Similar to #31549, #32672, #34357, and #40480 we should reject EOL versions at the directory authority level. This time version 0.3.5 is concerned.
We started the whole process this week and are about to contact all relay operators with a valid contact info. Additionally, we sent an announcement to [tor-relays@](https://lists.torproject.org/pipermail/tor-relays/2022-February/020289.html).Tor: 0.4.7.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40480Reject relays running Tor 0.4.2, 0.4.3, and 0.4.42023-12-03T18:23:05ZGeorg KoppenReject relays running Tor 0.4.2, 0.4.3, and 0.4.4Similar to #31549, #32672, and #34357 we should reject EOL versions at the directory authority level. This time version 0.4.2, 0.4.3, and 0.4.4 are concerned.
We started the whole process last week and have contacted all relay operators...Similar to #31549, #32672, and #34357 we should reject EOL versions at the directory authority level. This time version 0.4.2, 0.4.3, and 0.4.4 are concerned.
We started the whole process last week and have contacted all relay operators with a valid contact info so far. Additionally, we sent an announcement to [tor-relays@](https://lists.torproject.org/pipermail/tor-relays/2021-October/019862.html).Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40817Allow directory authorities to reject descriptors with EOL Tor versions2023-11-16T06:02:56ZGeorg KoppenAllow directory authorities to reject descriptors with EOL Tor versionsSo, we have the option that directory authorities recommend Tor versions but it seems there is no way right now to just set an option that blocks old Tor versions unless this is taken care of by a new Tor release. While in theory we coul...So, we have the option that directory authorities recommend Tor versions but it seems there is no way right now to just set an option that blocks old Tor versions unless this is taken care of by a new Tor release. While in theory we could try to just get those new Tor releases deployed as we decide EOL versions need to go the fact that we often need to treat bridges differently (as they are scarce) makes that route a bit cumbersome as we'd need to convince `Serge` not to update to such a new Tor version yet. Things get really complicated if we want the directory authorities to deploy a Tor security update after that as for `Serge` we'd then need a backout of the "block EOL versions" part.
In order to avoid all that hassle it would be nice to have some option directory authorities could set to block particular old Tor versions without the need for a new Tor release. That would make the whole EOL process easier for a *lot* of involved parties (right now we need to get dirauths to block all the fingerprints and then once a bunch of relay operators get back to us one by one after the upgraded their Tor version those fingerprints need to get unblocked again...).trinity-1686atrinity-1686ahttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/174Send authentication cookie to onbasca2023-10-05T16:33:55Zmeskiomeskio@torproject.orgSend authentication cookie to onbascaLet's add a header with an authentication cookie.Let's add a header with an authentication cookie.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850Disable Plaintext HTTP Clearnet Connections2023-10-04T03:24:25ZTracDisable Plaintext HTTP Clearnet ConnectionsI think that the Tor Browser Bundle should aim to disable allowing connections to plaintext HTTP websites out the box by the end of the year 2016.
Content injection into MITM'd clearnet HTTP connections is the number one security threat...I think that the Tor Browser Bundle should aim to disable allowing connections to plaintext HTTP websites out the box by the end of the year 2016.
Content injection into MITM'd clearnet HTTP connections is the number one security threat to Tor users. It's incredibly easy to do and I'm certain that it happens all the time. (You can reproduce this easily by going to http://example.com in the latest TBB. https://example.com is completely valid, but the connection to the plaintext version is made).
Even without direct content injection, it's the obvious weak point in the overall privacy that Tor provides for a common TBB user.
It's 2016 - the vast majority of websites now serve pages over SSL. Thanks to projects like Let's Encrypt, it's now completely easy and free to run SSL out of the box with any important web server software package - there's really no excuse not to be running HTTPS.
Rather than making this change immediately, we could announce the intention to release the change by the end of the year, thereby giving any stragglers time to add SSL to their websites. We could look at how browsers like Chrome and Firefox degrade deprecated TLS ciphers in successive releases as an example - first a visual indication, then a confirmation warning, then a total block.
What do you think?
**Trac**:
**Username**: miserlou2Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40748Change the default of relays per IP address to 42023-05-31T13:11:24ZGeorg KoppenChange the default of relays per IP address to 4Over in #40744 we started allowing 4 relays per IP address via the `AuthDirMaxServersPerAddr` option. I think we should raise the current default, which is 2, accordingly and then update all the specs affected. We might even need a new p...Over in #40744 we started allowing 4 relays per IP address via the `AuthDirMaxServersPerAddr` option. I think we should raise the current default, which is 2, accordingly and then update all the specs affected. We might even need a new proposal for that (including following the whole proposal process)?Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/163export num of bridges per ratio into prometheus2023-05-30T07:45:07Zmeskiomeskio@torproject.orgexport num of bridges per ratio into prometheusCan we add a metric to see how many bridges are per ratio? Something like: https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/152#note_2888840
We could use a counter with a label for the ratio. The problem is that prometh...Can we add a metric to see how many bridges are per ratio? Something like: https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/152#note_2888840
We could use a counter with a label for the ratio. The problem is that prometheus doesn't handle well having too many different values for the label. We could to pack the ratios together on 0.1 steps and decide a maximum value that we just count together everything above that. I'm not sure if we'll be able to plot this nicelly in graphana or if there are better tools in prometheus for this.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/web/community/-/issues/259What happens to bad relays - outdated2023-05-11T18:39:05ZcypherpunksWhat happens to bad relays - outdatedThe page https://community.torproject.org/relay/community-resources/bad-relays/ lists three things that can happen with bad relays: BadExit, Invalid and Reject. As of now, relay cannot be made Invalid (since proposal 272), but can (or no...The page https://community.torproject.org/relay/community-resources/bad-relays/ lists three things that can happen with bad relays: BadExit, Invalid and Reject. As of now, relay cannot be made Invalid (since proposal 272), but can (or not yet? should be clarified) become MiddleOnly.https://gitlab.torproject.org/tpo/core/tor/-/issues/40688dirauth: Remove Faravahar from code2023-02-08T15:22:59ZDavid Gouletdgoulet@torproject.orgdirauth: Remove Faravahar from codeRemove `Faravahar` from the code until its operator can bring it back online outside Team Cymru's network.Remove `Faravahar` from the code until its operator can bring it back online outside Team Cymru's network.Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40194provide relay health prometheus metrics via MetricsPort2023-02-07T10:25:16Znusenuprovide relay health prometheus metrics via MetricsPorttor recently got support for `MetricsPort` in v0.4.5.1-alpha (#40063).
For more context to this feature request see:
https://lists.torproject.org/pipermail/tor-dev/2019-February/013655.html
I'm proposing to add the following prometheus...tor recently got support for `MetricsPort` in v0.4.5.1-alpha (#40063).
For more context to this feature request see:
https://lists.torproject.org/pipermail/tor-dev/2019-February/013655.html
I'm proposing to add the following prometheus metrics (incl. labels), all metrics show absolute counters since tor started:
(feel free to add constraints like reducing granularity of counters or only updating counters once every x minutes for safety reasons)
## on exit relays (DNS related metrics)
* tor_relay_exit_dns_errors{reason="timeout"}
* tor_relay_exit_dns_errors{reason="SERVFAIL"}
* tor_relay_exit_dns_errors{reason="REFUSED"}
DNS RCODEs:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
I'm not sure if this is even visible to tor (unless ServerDNSResolvConfFile is used)
but if possible this kind of data would ideally be available for each resolver IP so the relay operator can detect and disable the faulty resolver:
* tor_relay_exit_dns_errors{reason="timeout", resolver="1.1.1.1"}
* tor_relay_exit_dns_errors{reason="timeout", resolver="8.8.8.8"}
* ...
* tor_relay_exit_maxdnsqueriespercircuit max amount of DNS queries caused by a single circuit since tor started
* exit stats as defined in (if enabled in torrc)
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1197
## other relay metrics
* tor_memory_bytes total amount of memory used by the tor process in bytes
* tor_relay_dos_circuitskilledwithtoomanycells
* tor_relay_dos_circuitsrejected
* tor_relay_dos_markedaddress
* tor_relay_dos_connectionsclosed
* tor_relay_dos_singlehopclientsrefused
* tor_relay_dos_introduce2rejected
* tor_relay_opencircuits currently open tor circuits
* tor_relay_connections{v="v1",direction="initiated"}
* tor_relay_connections{v="v1",direction="received"}
* tor_relay_connections{v="v2",direction="initiated"}
* tor_relay_connections{v="v2",direction="received"}
* tor_relay_connections{v="v3"...
* tor_relay_traffic{direction="sent"} total traffic sent in bytes
* tor_relay_traffic{direction="received"} total traffic received in bytes
* tor_relay_circuit_handshakes{proto="TAP"}
* tor_relay_circuit_handshakes{proto="NTor"}
* tor_relay_uptime tor process uptime in seconds
* tor_relay_version used tor version
* tor_relay_version_recommended boolean to indicate whether the used version is recommended
* ...
## Flags
* tor_relay_flag_stable
* tor_relay_flag_guard
* tor_relay_flag_exit
* tor_relay_flag_...
Some more:
- amount of closed/failed circuits broken down by their reason value
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1402
- amount of closed/failed OR connections broken down by their reason value
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2202
- cell stats (if enabled in torrc)
as defined in:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1137Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40387relay: Some metrics exported are being reset by rephist2023-02-07T10:25:08ZDavid Gouletdgoulet@torproject.orgrelay: Some metrics exported are being reset by rephistTurns out that some of the `rephist` metrics we are exporting are getting reset at every heartbeat in particular assigned onionskin stat in `rep_hist_log_circuit_handshake_stats()`Turns out that some of the `rephist` metrics we are exporting are getting reset at every heartbeat in particular assigned onionskin stat in `rep_hist_log_circuit_handshake_stats()`Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40448dirauth: New flag that only allow relays to be in the middle position2023-02-07T10:24:56ZDavid Gouletdgoulet@torproject.orgdirauth: New flag that only allow relays to be in the middle positionThere was a time before proposal [272](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/272-valid-and-running-by-default.txt) where removing the `Valid` flag would make the relay to be only used in the middle position...There was a time before proposal [272](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/272-valid-and-running-by-default.txt) where removing the `Valid` flag would make the relay to be only used in the middle position as in not Guard nor Exit by clients.
This ticket is to propose that we add a new relay flag that authorities can vote on in order to restrict the "power positions" (Guard and Exit and HSDir) to be only middle and rendezvous.
The main reason this would be desirable is because the Health Team often deals with large set of relays showing up that are either missing proper configuration (ex: `MyFamily`) or have the proper configuration but for which our assessment is that we are unsure and need to validate some key things that can be dragged over weeks like contacting the operator(s) for instance.
And so, if we could have a way to put these relays in a less powerful position that is middle and rendezvous only, it would allow us to put them in a "provisional" state (or the Matrix train station ;) until we can properly assess risk. We believe it is a better trade off than instead rejecting them outright and risking to loose good contributors to this drastic practice.
Of course, we are aware that even a middle node can still pull off attacks but we still think this could be a useful option for the health team nevertheless.
This would require couple things:
- A spec proposal.
- A config option (torrc) to indicate which relays have that flag like: `AuthDirTrainStation` (not a final name...)
-----
Current plan:
* [x] Write a proposal for doing the calculation as part of directory voting.
* [x] Voting-side implementation
* [x] Consensus-side implementationTor: 0.4.7.x-stableNick MathewsonNick Mathewson