The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-27T21:47:32Zhttps://gitlab.torproject.org/tpo/onion-services/oniongroove/-/issues/1Oniongroove deployment research2024-03-27T21:47:32ZSilvio RhattoOniongroove deployment researchResearch on all relevant deployment technologies (DevOps) for Onion Services: build a first matrix of technologies, recipes and strategies, incorporating it into the specs (onion-support#40).Research on all relevant deployment technologies (DevOps) for Onion Services: build a first matrix of technologies, recipes and strategies, incorporating it into the specs (onion-support#40).Oniongroove 0.1.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/community/support/-/issues/40093Provide a recommended set of iptables/nftables rules to help in case of DoS a...2023-07-14T15:15:42ZGeorg KoppenProvide a recommended set of iptables/nftables rules to help in case of DoS attacksA bunch of DoS attacks are essentially ongoing since June 2022 and we discussed a bunch of potential solution to improve things for our users. One thing folks started to experiment with is trying to come up with good iptables rules to he...A bunch of DoS attacks are essentially ongoing since June 2022 and we discussed a bunch of potential solution to improve things for our users. One thing folks started to experiment with is trying to come up with good iptables rules to help fighting ongoing attacks.
This ticket is for collecting all the information we gathered so far and coming up with some rules we can recommend to our relay operators (and updating our support guidelines accordingly).https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/129GetTor is not replying to emails2023-07-24T16:18:41ZGusGetTor is not replying to emailsUsers from Iran reported that GetTor is not replying to them. I have tried myself and I didn't get a reply too.Users from Iran reported that GetTor is not replying to them. I have tried myself and I didn't get a reply too.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/network-health/team/-/issues/270Conduct a privacy impact assessment of monitoring tools with an external party.2024-03-07T14:43:14ZGabagaba@torproject.orgConduct a privacy impact assessment of monitoring tools with an external party.In this issue, we will engage a third party to conduct a privacy impact assessment of the tools developed in the Objective 1 of the [project 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues).
The goal of this as...In this issue, we will engage a third party to conduct a privacy impact assessment of the tools developed in the Objective 1 of the [project 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues).
The goal of this assessment is to investigate whether or not these tools impact the privacy of relay operators and to ensure that these tools are working in the most rights-preserving ways possible. Should issues be discovered in this assessment, we will take recommended action to remedy them. This assessment will include both public- and internal-facing components of these tools. We will make a redacted, summarized, and/or plain language version of this report public.
- [ ] Create RFP To find consultants
- [ ] Send to consultantsGabagaba@torproject.orgGabagaba@torproject.org2024-05-06https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41335Establish a common onboarding template for both browsers2024-02-15T14:50:07ZdonutsEstablish a common onboarding template for both browsersTor Browser's current onboarding template is a port of an older version from Firefox. We should explore alternatives here before deciding on a template, e.g. the practicality of modifying Firefox's current built-in format.Tor Browser's current onboarding template is a port of an older version from Firefox. We should explore alternatives here before deciding on a template, e.g. the practicality of modifying Firefox's current built-in format.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/core/arti/-/issues/590shadow ci: dynamically generate configurations2022-10-31T20:39:31ZJim Newsomeshadow ci: dynamically generate configurationsIn the initial version of the Shadow CI, pending merge from https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/634, the shadow configuration file, network graph, and tor configuration files and keys are pre-generated and checke...In the initial version of the Shadow CI, pending merge from https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/634, the shadow configuration file, network graph, and tor configuration files and keys are pre-generated and checked in. These are lightly modified output of [tornettools](https://github.com/shadow/tornettools).
We should use tornettools to generate these dynamically instead. This may require extending tornettools and/or scripting some post-processing of its output.Jim NewsomeJim Newsomehttps://gitlab.torproject.org/tpo/core/torspec/-/issues/173pluggable transport socks k=v syntax2022-11-14T18:22:32ZIan Jacksoniwj@torproject.orgpluggable transport socks k=v syntaxThis is about the optional `k=v` parameters that can be specified in a `Bridge` line in torrc, and will then be passed to the PT via the SOCKS handshake.
According to the spec, the settings are to be `;`-separated; and the characters `\...This is about the optional `k=v` parameters that can be specified in a `Bridge` line in torrc, and will then be passed to the PT via the SOCKS handshake.
According to the spec, the settings are to be `;`-separated; and the characters `\` `=` `;` are supposed to be escaped. Implicitly, it seems to be trying to support arbitrary characters in both keys and values.
However, bridges are usually specified in Bridge lines, as found in the C Tor torrc (and as interpreted elsewhere). That means they ought to have a reasonable character set. Also, the Bridge line syntax does not have a way to spcify spaces within values (or key names).
Additionally, the code in C Tor does not conform to the specification. The actual behaviour is as follows: firstly the line is split on whitespace, by the general config line handling code. Then the `key=value` items are checked to see that they have a non-initial `=`; if not, it's an error. Then strings are subjected to `\`-escaping of only `\` and `;`, and concatenated together with `;`.
I suggest the following retcon:
* Document bridge lines as part of the official spec. They're an interechange format, not any longer a config detail of C Tor.
* Define a restricted character set for keys. Ideally we would say "C identifiers" like we do for transport names, but we don't want to break anything that is out there in the wild, so perhaps a wider character set should be allowed.
* Define a restricted character set for values. This should be fairly broad, probably, but it should be restricted to 7-bit ASCII printing characters at the very least. But, IMO it should be restricted further: for example, I think `\` `"` `'` here are rather undesirable.
For now in Arti I propose to implement roughly what C Tor does. The result will still not be capable of putting whitespace into values (or key names). And it would be less ergonomic than C Tor in the case where literal `\` are supposed to be specified, since Arti's config file is TOML and would need `\`-doubling (or the use of `'''`). I'm hoping that this is irrelevant.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/torspec/-/issues/172Ought a bridge to count as a hop?2024-03-13T07:58:24ZNick MathewsonOught a bridge to count as a hop?Currently our bridges count as one of the hops in a 3-hop circuit. We should make sure that decision is documented and explained.Currently our bridges count as one of the hops in a 3-hop circuit. We should make sure that decision is documented and explained.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/55Update description in Snowflake extension pages on Firefox and Chrome2023-06-27T18:34:40ZrayaUpdate description in Snowflake extension pages on Firefox and ChromeThere was a discussion in the Tor IRC channel that the description in the Snowflake extension Chrome webstore and Firefox add-ons page does not clearly distinguish between censored/uncensored users:
- https://addons.mozilla.org/en-GB/fir...There was a discussion in the Tor IRC channel that the description in the Snowflake extension Chrome webstore and Firefox add-ons page does not clearly distinguish between censored/uncensored users:
- https://addons.mozilla.org/en-GB/firefox/addon/torproject-snowflake/
- https://chrome.google.com/webstore/detail/snowflake/mafpmfcccpbjnhfhjnllmmalhifmlcie
Opening the issue to say that I could work on updating the description in the next hour if the priority is high!
cc: @arma @gus @shelikhoo @meskioCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/community/support/-/issues/40092CDR.Link is not opening new tickets2023-08-10T13:43:08ZGusCDR.Link is not opening new ticketsreported by @championquizzer and @nina to CDR Link support:
```
Since yesterday our support team (cc'ed in the email) has been receiving
a lot of user support tickets from users in Iran via the
@TorProjectSupportBot on Telegram. We are ...reported by @championquizzer and @nina to CDR Link support:
```
Since yesterday our support team (cc'ed in the email) has been receiving
a lot of user support tickets from users in Iran via the
@TorProjectSupportBot on Telegram. We are running into the following
issues on our cdr.link instance:
1. We reached a limit of 200 tickets somewhere around early morning (UTC
time) today and haven't been receiving any new tickets ever since.
2. For the tickets we currently have in queue, response delivery is
failing with the error "Delivery failed: "Unable to send telegram
message: 400 Bad Request"
I'd appreciate if you can please look into this. Thanks a lot!
```GusGushttps://gitlab.torproject.org/tpo/core/torspec/-/issues/171Proposal for Bring Accessible TLS Supports to All Onion Services2023-05-11T16:54:42ZshelikhooProposal for Bring Accessible TLS Supports to All Onion ServicesCurrently, it is difficult to create a TLS certificate for onion services, since all existing free CA is unwilling to issue certificate for onion service for various reasons. And existing CA that issue certificate to onion services are p...Currently, it is difficult to create a TLS certificate for onion services, since all existing free CA is unwilling to issue certificate for onion service for various reasons. And existing CA that issue certificate to onion services are paid, so it is forcing a difficult decision on onion service operators when it comes to choosing between (security and features) or anonymity.
So, here is the proposal for a better certificate system for onion services:
## Generate a CSR
To create a CSR, generate the private and public key pair as usual, and create normal certificate field and extensions for that certificate. SAN, subject name must equal to onion address.
Use the onion key to sign the public key and extensions, then put this signature into the certificate sign request as a non-critical extension.
The valid onion address CSR created in this procedure is known as onion certificate seed.
## Generate a Certificate
To generate a certificate, there are two possible routes:
### Self sign the certificate
Copy all the extensions and self-sign directly.
### Expand the certificate by expand the certificate at a CA
Send the onion certificate seed CSR to any CA, CA will check if the extension contains a valid signature, all extension are allowed, and SAN, subject name must equal to onion address. If so, issue a certificate. This CA can be setup by Tor Project, or another organization.
## Verify the certificate
### Tor Native Application Like Tor Browser
Do not trust any additional CA. Whenever encountered a leaf certificate with onion key signature, if the signature pass the check in the same way as expansion CA does, then it is considered to be issued by a trusted CA.
### Other application that don't understand onion key signature extension
Add the root certificate of expansion CA (skip this step if the CA is already trusted by default), and verify normally.
## Advantages
In this design, for Tor Native Application, there is no additional trust put in 3rd party as the certificate have embedded proof. The operator can choose any expansion CA or self-sign without worried about fail the verification.
For other application, the certificate can still be verified with standard logic by trusting the expansion CA. In the beginning, we can run an expansion CA that is not trusted by default to work with non-Tor native application. In the end, someone else can seamlessly use their trusted by default CA to issue certificate to onion services.
**Comments are welcomed**
## Comparsion with onion-x509
[onion-x509](https://github.com/ahf/onion-x509) attempt at solving this issue by converting the onion key into a CA that can be used to sign other certificates by anchor the trust at onion key. However, there is no easy way to get existing application to work with this system, like importing an expansion CA's root.https://gitlab.torproject.org/tpo/core/arti/-/issues/581better way to keep required features and documentation synced2023-01-24T16:32:17Ztrinity-1686abetter way to keep required features and documentation synced!681 added annotations so rustdoc print what features need to be enabled to get access to a given function/module/structure/field, and a script to help keeping everything in sync. That script is far from perfect, in !713 I tried making i...!681 added annotations so rustdoc print what features need to be enabled to get access to a given function/module/structure/field, and a script to help keeping everything in sync. That script is far from perfect, in !713 I tried making it learn new tricks, and in !721 Diziet tried to replace it with something that does more than pattern matching and actually understand a bit of rust. The first approach won't ever be exhaustive and has edge case everywhere (like at line-breaks), and the second will probably be more work than it's worth, while possibly not being exhaustive either.
On !721 I proposed a different scheme, instead of trying to parse rust ourselves, what if we let rustdoc do what it does (1) with no feature, (2) with all features, and (3) ask it about what it thinks requires feature. If `(2) - (1) == (3)`, everything is fine. If not, some `cfg_attr` needs to be updated.
The main issue with that approach is it won't tell us if the `cfg_attr` is exactly the good one (doing so would be very expensive), and it will fail to acknowledge `target_family`, `target_arch` and `target_os`. That second part is not as bad as it could be given we use these mostly in context where `feature(doc_auto_cfg)` works, and we don't use many of these on our public interface.https://gitlab.torproject.org/tpo/core/torspec/-/issues/170Path spec WbX are all "Weight for Guard+Exit-flagged nodes for BEGIN_DIR requ...2022-11-14T18:25:18ZHackerNCoderhackerncoder@encryptionin.spacePath spec WbX are all "Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests"path-spec.txt line 354 to 357 state:
Wbg - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
Wbm - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
Wbe - Weight for Guard+Exit-flagged nodes for BEGIN_DIR r...path-spec.txt line 354 to 357 state:
Wbg - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
Wbm - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
Wbe - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
Wbd - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
I don't think it's correct that they are all the Weight for Guard+Exit-flagged nodes?https://gitlab.torproject.org/tpo/core/arti/-/issues/566Better developer documentation for Windows developers2023-06-13T17:28:49ZAlexander Færøyahf@torproject.orgBetter developer documentation for Windows developersIn https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/705 Nick suggests that we add some more information here from our AppVeyor builds to the build documentation of Arti to make it easier for Windows developers to get started....In https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/705 Nick suggests that we add some more information here from our AppVeyor builds to the build documentation of Arti to make it easier for Windows developers to get started.
We should follow up on that, but is not strictly urgent.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/564Make tor-rtcompat traits sealed in 1.02022-10-20T21:10:44ZNick MathewsonMake tor-rtcompat traits sealed in 1.0We've realized today that, although `tor-rtcompat` is an important piece of our public API, we do not currently plan to declare it `1.0`. That is, we need to make sure that we can continue to improve its feature set even as we keep `art...We've realized today that, although `tor-rtcompat` is an important piece of our public API, we do not currently plan to declare it `1.0`. That is, we need to make sure that we can continue to improve its feature set even as we keep `arti_client` stable.
To do this, we plan to make the traits in `tor-rtcompat` sealed by default for now, with an optional `unseal-traits` feature to unseal them.
@Diziet has taken this on.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/12Add Early Data support to WebTunnel2024-02-27T19:06:29ZshelikhooAdd Early Data support to WebTunnelCurrently, the early data support(send first chunk of client data together with HTTP GET Request) is not implemented in WebTunnel.
This can slightly increase performance at the cost of increased code complexity.Currently, the early data support(send first chunk of client data together with HTTP GET Request) is not implemented in WebTunnel.
This can slightly increase performance at the cost of increased code complexity.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/9Fix unreliable bufio usage in HTTP Upgrade transport2024-02-27T19:08:49ZshelikhooFix unreliable bufio usage in HTTP Upgrade transportCurrently, there are a few TODO marked bufio usage that are unreliable as the buffer is not drained before original buffer is reused.Currently, there are a few TODO marked bufio usage that are unreliable as the buffer is not drained before original buffer is reused.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/8Add Tor PT Log feedback to WebTunnel Client2024-02-27T19:08:35ZshelikhooAdd Tor PT Log feedback to WebTunnel Client[Add](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/1#note_2832380) Tor PT Log feedback will make it easier to debug issues in the pluggable transport.[Add](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/1#note_2832380) Tor PT Log feedback will make it easier to debug issues in the pluggable transport.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/web/support/-/issues/310Instructions on setting up bridge relay for Debian / Ubuntu2024-01-30T13:34:35ZRedhill54Instructions on setting up bridge relay for Debian / Ubuntu
1 I am writing about a problem that I had when setting up a Tor bridge relay on a machine with an Ubuntu operating system.
2 On 13 August I put a question with the title “Change instructions or add alternative for adding gpg keys” ...
1 I am writing about a problem that I had when setting up a Tor bridge relay on a machine with an Ubuntu operating system.
2 On 13 August I put a question with the title “Change instructions or add alternative for adding gpg keys” onto Tor Stack Exchange. The link to the question is
A https://tor.stackexchange.com/questions/23269/change-instructions-or-add-alternative-for-adding-gpg-key
3 The one answer received suggested that I put the problem as an issue for the people who manage the website which includes the Tor bridge relay instructions, which is what I am now doing.
4 I followed the instructions on setting up a bridge relay in Ubuntu that I found in two different webpages. The instructions were identical in both webpages as follows.
B https://support.torproject.org/apt/tor-deb-repo/
C https://support.torproject.org/apt/
5 I installed a new version of Lubuntu on a computer, replacing all the programs and data, and then installed the programs for a Tor bridge relay.
6 There was a problem with the gpg key instructions. On Tor Stack exchange I found some advice in the answers to the question “Problem with adding gpg while installing Tor browser: Permission denied” at the link below.
D https://tor.stackexchange.com/questions/23212/problem-with-adding-gpg-while-installing-tor-browser-permission-denied
7 This advice enabled me to get the bridge relay running, but I could not find a way to run nyx using the command “nyx”, but had to use “sudo nyx”. The nyx system gives messages stating that using “sudo nyx” should not be necessary, but if I used “nyx” I got requests for Authentication passwords, or a cookie authentication file, and I could not figure out the password required or gain access to the cookie authentication file. I am aware that it is possible that there may be ways to find the right password or gain access to the cookie authentication file, but I would need further instructions on those actions.
8 Some days later I saw the instructions in the webpage from the link below.
E https://support.torproject.org/relay-operators/
These instructions and commands were different from the instructions at the links B and C. I wonder if the instructions at link E, which includes some shorter commands and fewer “sudo” commands. (NB in the instructions at links B and C, “#” is shorthand for “sudo”).
9 My question is whether the instructions at link E are more up-to-date, and will avoid the need for the change mentioned in link D, and remove the need for the “sudo nyx” command. If this is the case, I presume that the instructions at links B and C will need to be changed in line with those at link E.
10 If you confirm that the instructions at link E should be used, rather that those at links B, C, and D, then I will repeat the process of loading Ubuntu onto the computer and installing the Tor bridge relay, and see if that works as it should.
With thanks in advance for looking at this issue,
Redhill54https://gitlab.torproject.org/tpo/core/arti/-/issues/559add CI test which searches logs for sensitive data2022-10-20T21:12:53ZIan Jacksoniwj@torproject.orgadd CI test which searches logs for sensitive dataWe should add a test to the CI that greps the integration test logs for as many of the things mentioned in `doc/Safelogging.md` as we can.
We can use the existing logs, which run with a high verbosity level, and filter them (post-hoc, i...We should add a test to the CI that greps the integration test logs for as many of the things mentioned in `doc/Safelogging.md` as we can.
We can use the existing logs, which run with a high verbosity level, and filter them (post-hoc, in an ad-hoc way) for severity.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org