The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-11-28T14:01:05Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40716Impelement conflux for onion services2022-11-28T14:01:05ZMike PerryImpelement conflux for onion servicesConflux is traffic splitting, and will result in increased throughput and reduced latency for onion services after a connection has been established, by routing traffic over multiple paths, or via the lowest latency path to a service.
T...Conflux is traffic splitting, and will result in increased throughput and reduced latency for onion services after a connection has been established, by routing traffic over multiple paths, or via the lowest latency path to a service.
This ticket is for the onion service pieces of conflux (https://gitlab.torproject.org/tpo/core/tor/-/issues/40593).
We will not be implementing the onion services pieces of conflux as part of that ticket. It can be done later, if any onion service sponsors care about latency or throughput.
The pieces for onion services are:
- **Negotiation**
- [ ] Protover Advertisement for Onions (24h)
- [ ] Rend circuit linking (40h)
This is specified in https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/329-traffic-splitting.txt, but we probably want to allow onion services to configure their scheduler by manually choosing either BLEST, or LowRTT, since different kinds of onion services may want to optimize for either throughput or latency.
There may be some additional work wrt making sure linked edge conns work properly, if they are handled differently for the onion service case.
Also, some shadow validation and performance testing will be needed. Maybe 40h or so of dev time (though much longer wall-clock time).https://gitlab.torproject.org/tpo/core/tor/-/issues/40717Additional metricsport stats for various stages of onionservice handshake2023-12-07T14:41:35ZMike PerryAdditional metricsport stats for various stages of onionservice handshakeIf we export additional onion service metrics such as time measurements on the HSDIR, INTRO, and REND stages of circuit setup for both client and service side, and the number of timeouts/failures there, it would help to uncover the root ...If we export additional onion service metrics such as time measurements on the HSDIR, INTRO, and REND stages of circuit setup for both client and service side, and the number of timeouts/failures there, it would help to uncover the root cause of issues like https://gitlab.torproject.org/tpo/core/tor/-/issues/40570 and related reliability and connectivity issues with onion services.
We can also export congestion control info from https://gitlab.torproject.org/tpo/core/tor/-/issues/40708 to the onionservice metrics set, too, which can help us with tuning congestion control for onion services.
We can then hook up the onionperf onion service instances to our grafana dashboard, and gather more detailed stats that way, as a supplement to the metrics that get graphed on the metrics website.https://gitlab.torproject.org/tpo/core/arti/-/issues/651Basic acceptance testing for 1.1.0 deliverables2023-01-10T18:23:24ZNick MathewsonBasic acceptance testing for 1.1.0 deliverablesHere's what we should test to make sure that 1.1.0 behaves as advertised.
Please add more cases as needed. In each case, it would be nice to have integration testing, but we should at a minimum test these cases by hand.
## Successful ...Here's what we should test to make sure that 1.1.0 behaves as advertised.
Please add more cases as needed. In each case, it would be nice to have integration testing, but we should at a minimum test these cases by hand.
## Successful cases
* [x] Configure Arti with a single bridge, not using a pluggable transport.
* [x] Configure Arti with a single bridge, using obfs4. (#332)
* [x] Configure Arti with a single bridge, using snowflake. (#333)
* [ ] Configure Arti with multiple bridges, including a few nonexistent ones.
In each of the successful cases, we should:
* Observe that we can browse and download successfully.
* Observe that the log messages are reasonable-looking at level `info` and higher.
* Observe (using instrumentation, `lsof`, `tcpdump`, or similar) that Arti is only connecting as it is told.
You can get bridges from `bridges.torproject.org`.
## Failing cases
* [ ] Configure arti to use bridges, using only a single nonexistent bridge.
* [ ] Configure arti to use bridges, using multiple nonexistent bridges.
In the failing cases we should:
* Observe that the log messages are reasonable-looking at level `info` and higher.
* Observe (using instrumentation, `lsof`, `tcpdump`, or similar) that Arti is only connecting as it is told.
## Complex cases
* [ ] Configure a list of bridges, and turn enable_bridges on and off. Make sure that Arti behaves correctly.Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/community/training/-/issues/79Introduction to Onion Services in Arabic2023-07-19T11:33:24ZrayaIntroduction to Onion Services in Arabic## To-Do:
- [ ] Complete translation of slides
- [ ] Upload to community portal
## Steps to upload to community portal
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/stat...## To-Do:
- [ ] Complete translation of slides
- [ ] Upload to community portal
## Steps to upload to community portal
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/static/files, simply as `file-name.odp` and `file-name.pdf`
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/community/training, inside folder: `year/topic/file-name.odp` and `year/topic/file-name.pdf`
- [ ] add preview image of slides here (size H:700, W:400): https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/static/images/training, this image will be displayed here: http://community.torproject.org/training/resources, simply add as `file-name.png`
- [ ] edit the `training-resources.json` file and add training properties: https://gitlab.torproject.org/tpo/web/community/-/blob/main/databags/training-resources.json
- [ ] edit the `community-training-materials.json` file and add training properties:
https://gitlab.torproject.org/tpo/web/community/-/blob/main/databags/community-training-materials.json
### Working document
- https://docs.google.com/presentation/d/1Mlyzjfvcr5qI4hZlNMzF87iKBADX7EmVVFqn5rJfNqY/editrayarayahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41479Verify browser.startup.homepage_override.buildID and update mechanisms2023-10-09T17:00:12ZPier Angelo VendrameVerify browser.startup.homepage_override.buildID and update mechanismsWe have a mechanism to make `about:tor` open an update page, with a few preferences involved.
We should review it.
Also, we write `browser.startup.homepage_override.buildID`, and so we could possibly remove it from the profile.We have a mechanism to make `about:tor` open an update page, with a few preferences involved.
We should review it.
Also, we write `browser.startup.homepage_override.buildID`, and so we could possibly remove it from the profile.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41482Bridge cards should inform users when a bridge isn't working2024-01-29T19:06:20ZGusBridge cards should inform users when a bridge isn't workingWhen a user requests a bridge using one of the bridge distributors (moat, telegram, connection assist), some of them may be blocked in their region. Users can see which bridge is failing on their Tor logs. Is it possible to display that ...When a user requests a bridge using one of the bridge distributors (moat, telegram, connection assist), some of them may be blocked in their region. Users can see which bridge is failing on their Tor logs. Is it possible to display that information on the bridge card so they don't need to check the logs?https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/112Reported as offline in metrics, some bridges are online and running2024-02-29T15:22:53ZGusReported as offline in metrics, some bridges are online and runningSince last week, some bridge operators are reporting that their bridge is 'offline' in Metrics, but they are online and running.
I can confirm that this is happening. One of my bridges is marked as [offline](https://metrics.torproject....Since last week, some bridge operators are reporting that their bridge is 'offline' in Metrics, but they are online and running.
I can confirm that this is happening. One of my bridges is marked as [offline](https://metrics.torproject.org/rs.html#details/25A5B3BB5449EC5A0D4AE4DB657899C02C186EBE), but on the tor logs I see:
>Nov 28 12:02:57.000 [notice] Heartbeat: Since last heartbeat message, I have seen 200 unique clients.
Other messages on the logs:
```
Nov 20 12:23:29.000 [notice] Guard bauruine ($5B83DC983406651A0B4F6AE1940793CDD6A6F92E) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 198/283. Use counts are 63/63. 227 circuits completed, 0 were unusable, 30 collapsed, and 5 timed out. For reference, your timeout cutoff is 324 seconds.
Nov 20 23:04:10.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 5983/6034). That's ok. We will try to fetch missing descriptors soon.
Nov 21 03:24:31.000 [notice] Guard rixtyminutes ($01AE2DE314276C82FCCC3603A1C2F3238E6544C9) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 109/156. Use counts are 37/37. 132 circuits completed, 0 were unusable, 23 collapsed, and 5 timed out. For reference, your timeout cutoff is 324 seconds.
```
Reddit: https://www.reddit.com/r/TOR/comments/z2o7ro/bridge_metrics_showing_offline/meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/665Reject overlapping pluggable transport protocol configs2023-01-18T14:51:36ZetaReject overlapping pluggable transport protocol configsThe following discussion from !886 should be addressed:
- [ ] @Diziet started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/886#note_2856541):
> Sorry about that. Please file a ticket along the lines...The following discussion from !886 should be addressed:
- [ ] @Diziet started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/886#note_2856541):
> Sorry about that. Please file a ticket along the lines of "we should reject overlapping pt protocol configs" and feel free to assign it to me.Arti 1.1.0: Anticensorship readyIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/674pt transports configuration is not properly tested2023-06-20T13:51:20ZIan Jacksoniwj@torproject.orgpt transports configuration is not properly testedWe don't test an entry in `[[bridges.transports]]`.
See `arti/crates/arti/src/cfg.rs`, `TODO` near `CONFIG_KEYS_EXPECT_NO_EXAMPLE`We don't test an entry in `[[bridges.transports]]`.
See `arti/crates/arti/src/cfg.rs`, `TODO` near `CONFIG_KEYS_EXPECT_NO_EXAMPLE`Arti 1.1.0: Anticensorship readyIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/677More debug logs in pluggable transports2023-06-20T13:54:59ZNick MathewsonMore debug logs in pluggable transportsSpecifically, it would be good to have more debugging logs throughout the PT lifecycle, and to have trace logs for every step of the way along making a connection, negotiating with the proxy, etc. I have some `stashed` junk that I used ...Specifically, it would be good to have more debugging logs throughout the PT lifecycle, and to have trace logs for every step of the way along making a connection, negotiating with the proxy, etc. I have some `stashed` junk that I used in debugging, but it isn't production quality.Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/core/arti/-/issues/681Resolve remaining comments from !901 and !9032023-02-27T12:00:34ZNick MathewsonResolve remaining comments from !901 and !903The reviews of !901 and !903 had some suggestions, mainly related to commenting and documentation. We should apply those before we forget about them entirely.The reviews of !901 and !903 had some suggestions, mainly related to commenting and documentation. We should apply those before we forget about them entirely.Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/core/arti/-/issues/682Try to recover our unit test coverage post arti-1.1.02023-04-25T15:37:35ZNick MathewsonTry to recover our unit test coverage post arti-1.1.0With 1.1.0, our unit test coverage has dropped to 78.06%. This is the [lowest unit test coverage](https://gitlab.torproject.org/tpo/core/arti/-/wikis/ReleaseHistory) level on ANY release of arti that we have ever done: ouch!
It's time ...With 1.1.0, our unit test coverage has dropped to 78.06%. This is the [lowest unit test coverage](https://gitlab.torproject.org/tpo/core/arti/-/wikis/ReleaseHistory) level on ANY release of arti that we have ever done: ouch!
It's time to look at our [coverage results](https://tpo.pages.torproject.net/core/arti/coverage/unit/) and see where we need to write tests. Let's not scrimp here: our test coverage has saved us from bugs in the past!Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/core/arti/-/issues/702More unit tests for tor-ptmgr crate2023-02-27T12:00:40ZNick MathewsonMore unit tests for tor-ptmgr crateCurrent ptmgr unit test coverage is around 38%. Let's get that increased :)Current ptmgr unit test coverage is around 38%. Let's get that increased :)Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/community/training/-/issues/80All About Tor slides in Arabic2023-08-25T18:40:39ZrayaAll About Tor slides in Arabic## To-Do:
- [ ] Complete translation of slides
- [ ] Upload to community portal
## Steps to upload to community portal
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/stat...## To-Do:
- [ ] Complete translation of slides
- [ ] Upload to community portal
## Steps to upload to community portal
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/static/files, simply as `file-name.odp` and `file-name.pdf`
- [ ] add slides in PDF and ODP formats here: https://gitlab.torproject.org/tpo/community/training, inside folder: `year/topic/file-name.odp` and `year/topic/file-name.pdf`
- [ ] add preview image of slides here (size H:700, W:400): https://gitlab.torproject.org/tpo/web/community/-/tree/main/assets/static/images/training, this image will be displayed here: http://community.torproject.org/training/resources, simply add as `file-name.png`
- [ ] edit the `training-resources.json` file and add training properties: https://gitlab.torproject.org/tpo/web/community/-/blob/main/databags/training-resources.json
- [ ] edit the `community-training-materials.json` file and add training properties:
https://gitlab.torproject.org/tpo/web/community/-/blob/main/databags/community-training-materials.jsonrayarayahttps://gitlab.torproject.org/tpo/tpa/prometheus-alerts/-/issues/9Add alerts for network health relays2024-03-27T09:45:19ZGeorg KoppenAdd alerts for network health relaysWe have some relays and their metrics scraped via Prometheus (namely akka, ukko, d2d4, and Najdorf). We should work on alerts so we can avoid stumbling into some or all of the metrics not being exposed anymore in our dashboards due to $i...We have some relays and their metrics scraped via Prometheus (namely akka, ukko, d2d4, and Najdorf). We should work on alerts so we can avoid stumbling into some or all of the metrics not being exposed anymore in our dashboards due to $issue (as witnessed in tpo/network-health/team#281).
/cc @hiro, @dgouletGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/web/manual/-/issues/137Add section about crypto warning popup2022-12-17T15:19:26ZdonutsAdd section about crypto warning popupSee https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41363 for the most recent work happening on this component, and https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40899#note_2863965 for discussion...See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41363 for the most recent work happening on this component, and https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40899#note_2863965 for discussion about the support URL.
tl;dr we have a `Learn more` link in the wingpanel that currently points to support-dot, which presumably was a temporary measure until dedicated content could be created.https://gitlab.torproject.org/tpo/core/arti/-/issues/707have a way to get underlying file descriptors2023-01-18T14:07:23Ztrinity-1686ahave a way to get underlying file descriptorsCurrently the TCP/UDP types returned by a Runtime are opaque: there is no way to access the underlying file descriptor.
Access to that file descriptor is a requirement to implement transparent proxy (part of #72), and I suspect it woul...Currently the TCP/UDP types returned by a Runtime are opaque: there is no way to access the underlying file descriptor.
Access to that file descriptor is a requirement to implement transparent proxy (part of #72), and I suspect it would make onionmasq#23 easier (right now I think they'll have to implement their own TcpProvider, not wrapping arti default, to be able to get that).
It'll be kind of an issue with regard to crossplarformness: Windows has no FD, it has file handles which are mostly the same, but I guess different in some ways. Also some runtimes might not have backing fds for whatever reason, so returning a fd should probably be optionalArti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/711Use cargo-semver-checks or such to enforce stability in high-level APIs2023-05-31T18:41:09ZNick MathewsonUse cargo-semver-checks or such to enforce stability in high-level APIsThe `arti-client` crate depends on, and exposes, APIs from a bunch of other crates. As such, it is tricky to make sure that we haven't made any changes that **unintentionally** break compatibility with past versions of `arti-client`.
We...The `arti-client` crate depends on, and exposes, APIs from a bunch of other crates. As such, it is tricky to make sure that we haven't made any changes that **unintentionally** break compatibility with past versions of `arti-client`.
We should open other tickets (eg #710, #712) to limit the risk of breaking changes. But it would also be good to use what tooling we can to detect breaking changes, possibly as part of CI. We could, for example, enforce that there is a breaking semver change iff there is a BREAKING comment in semver.md.
The current front-runner seems to be [`cargo-semver-checks`](https://crates.io/crates/cargo-semver-checks), which claims to have no false positives (only false negatives). I haven't been able to figure out out to make it work, but hey, who knows.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40735[WARN] Tried connecting to router ... identity keys were not as expected2023-11-14T16:59:05Zcypherpunks[WARN] Tried connecting to router ... identity keys were not as expectedBackground: Tor Browser 12.0, Tor 4.7.12, Windows 7, vanilla bridges.
Repeatedly getting the following log line.
```
[WARN] Tried connecting to router at *address* ID=<none> RSA_ID=*FP1*, but RSA + ed25519 identity keys were not as exp...Background: Tor Browser 12.0, Tor 4.7.12, Windows 7, vanilla bridges.
Repeatedly getting the following log line.
```
[WARN] Tried connecting to router at *address* ID=<none> RSA_ID=*FP1*, but RSA + ed25519 identity keys were not as expected: wanted *FP1* + no ed25519 key but got *FP2* + *edFP*.
```
Ideas of what happened:
* MITM
* Bridge operator reinstalled it in-between me getting the bridge and now.
What is wrong:
* Bridge should be marked as unreachable: either it is not used already and connections are doomed to spend resources for nothing, or it should not be used as something is clearly wrong with it
* There should be a way to distinguish first idea from second - my best guess is building a tunneled directory connection to bridge authority and asking "Is there a bridge *FP2* and does it listen on *address*?"https://gitlab.torproject.org/tpo/core/arti/-/issues/717arti-based obfs4 quick reachability monitor2024-03-27T09:38:10ZRoger Dingledinearti-based obfs4 quick reachability monitorIn the "Better bridgestrap designs to quickly detect bridges going offline" section of https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035, I describe a tool we need that will notice when bridges go down ...In the "Better bridgestrap designs to quickly detect bridges going offline" section of https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035, I describe a tool we need that will notice when bridges go down / get blocked. One goal is to notice quickly enough that we can use the reachability result in the "bridge subscription" approach (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/42) where clients auto-ask for a replacement when one of their bridges goes down.
* [ ] Part one, a feature replacement for bridgestrap. That is, we need to take in a set of bridge lines to test (e.g. via an http post from rdsys, but we can do that interface however both sides like), launch connections to them, learn success or failure, and report it both in response to the request from rdsys and also write it out to a file like the ones here: https://collector.torproject.org/recent/bridgestrap/
* [ ] Part two, the new feature: we want to learn, for each bridge that we think is currently up, the moment that it goes down. The goal is that clients will start coming to rdsys asking for a replacement bridge when they think one of their bridges goes down, and we want rdsys to already have our 'ground truth' answer by the time the client makes that request. The naive approach would be to connect to each bridge every 10 seconds or something using the 'part one' approach from above. But I think the better option is to *hold open* connections to each bridge, and then notice when a connection breaks. We will still be subject to TCP issues where sometimes it takes a while to notice a broken connection, but this approach is a low-cost way to get results within a 60-ish second response time range.
Some details that make 'part two' more complicated than we might first think:
* We still need to launch new connections every so often too, to detect the case where the bridge stays up for existing connections but somehow gets firewalled for new ones. How often to launch those connections is a parameter we should explore, to find a good balance between being thorough vs limiting our overall connection volume.
* Can the obfs4proxy tool handle hundreds or thousands of client connections, or does something fail at that scale? I don't know the answer, but if we discover scaling issues, we should either debug and resolve them, or maybe we work around them and use them as motivation to switch to the "arti runs a rust obfs4 thread" model that we already want to get to eventually.
* If we simply make a connection to an obfs4 bridge and then try to hold it open, the bridge will expire and close that connection after a few minutes because it has no circuits on it. So we need to come up with a suitable trick for convincing the bridge to not expire the connection. Is making a one-hop circuit and leaving it open enough, or does it get expired after a while? How about if you put a dir stream on it? Worst case we can make a two-hop circuit, but it would be unfortunate if that's our best option: if we pick a new second hop each time, we undermine our bridge enumeration defenses (strategy 2 on https://blog.torproject.org/research-problems-ten-ways-discover-tor-bridges/), whereas if we pick one relay to use every time (e.g. Serge), everything fails if that relay goes away for a bit.
The eventual deployment vision is that (a) we run this tool in a safe uncensored location, where the goal is to get ground truth about upness; if it scales well we run one to test every bridge, or if needed we run a farm of them where each instance handles its fair share of the bridges, and then (b) we run one of these tools inside each censored area, where it does tests on demand and we only give it an address to test if our uncensored location says it's up but a threshold of clients have come to us saying it's down in their location.