The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-01-24T16:32:17Zhttps://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/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/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/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/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/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/community/relays/-/issues/56Evaluate proposals for relay operator code of conduct, policies, agreements a...2024-03-27T09:44:22ZGabagaba@torproject.orgEvaluate proposals for relay operator code of conduct, policies, agreements and methods for enforcementThis is activity O2.2 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Evaluate promising solutions for relay operator code of conduct, policies, agreements, and methods for enforcement. In this Ac...This is activity O2.2 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Evaluate promising solutions for relay operator code of conduct, policies, agreements, and methods for enforcement. In this Activity, our goal is to engage relay operators and gather feedback about potential solutions around establishing behavior expectations and clear consequences.
- Gather input from the community on any concepts developed in this project. This involves online events and discussions where we engage with relay operators in different phases of the relay operator life cycle.
- Develop recommendations for activities [2.3](https://gitlab.torproject.org/tpo/network-health/team/-/issues/267) and [2.4](https://gitlab.torproject.org/tpo/network-health/team/-/issues/268) based on the research findings and the relay operator personas definition developed as part of the OTF fellowship alongside input collected in this Activity.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/community/relays/-/issues/58Develop and implement solutions for operator codes of conduct, policies, agre...2024-03-27T09:44:55ZGabagaba@torproject.orgDevelop and implement solutions for operator codes of conduct, policies, agreements, and methods for enforcementThis is activity O2.3 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Develop and implement solutions for operator codes of conduct, policies, agreements, and methods for enforcement. The code of ...This is activity O2.3 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Develop and implement solutions for operator codes of conduct, policies, agreements, and methods for enforcement. The code of conduct will codify what we expect of relay operators rather than leaving it implicit, as it is now. These guidelines mirror our criteria for rejecting bad relays.
In this Activity we will:
- Publish clear guidelines for
1. Tor to consistently identify and reject malicious relays, and
2. Relay operators to understand what kind of behavior will not be tolerated and what steps are taken when certain activity is detected.
- Use criteria developed in [activity O2.1](https://gitlab.torproject.org/tpo/network-health/team/-/issues/265) to evaluate whether these behavior expectations and consequence solutions are appropriate per relay operator feedback.Georg KoppenGeorg Koppenhttps://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/onion-services/sauteed-onions/onion-csr/-/issues/1Add CI with basic Go tests2022-11-12T16:49:32ZRasmus Dahlbergrasmus@rgdd.seAdd CI with basic Go testsShould run go build / test / vet / fmt or similar.Should run go build / test / vet / fmt or similar.https://gitlab.torproject.org/tpo/onion-services/sauteed-onions/onion-csr/-/issues/2Clean-up dependency for parsing of hs_ed25519_secret_key2022-11-12T16:49:40ZRasmus Dahlbergrasmus@rgdd.seClean-up dependency for parsing of hs_ed25519_secret_keyRemove "bed25519" dependency in `pkg/okey` and instead implement the crypto.Signer interface in this repo, maybe using:
- https://pkg.go.dev/filippo.io/edwards25519
Note that it is not possible to use `crypto/ed25519` because the pri...Remove "bed25519" dependency in `pkg/okey` and instead implement the crypto.Signer interface in this repo, maybe using:
- https://pkg.go.dev/filippo.io/edwards25519
Note that it is not possible to use `crypto/ed25519` because the private key requires the seed, and what's stored in `hs_ed25519_secret_key` is the expanded seed after hashing and setting a few bits.https://gitlab.torproject.org/tpo/onion-services/sauteed-onions/onion-csr/-/issues/3Parse metadata of hs_ed25519_secret_key2022-11-12T16:49:47ZRasmus Dahlbergrasmus@rgdd.seParse metadata of hs_ed25519_secret_keyWe currently skip the first 32 bytes of the `hs_ed25519_secret_key` when parsing in `pkg/okey`. It would be nice to check that this initial metadata is not malformed.
Maybe a good place to start looking for inspiration: https://gitlab....We currently skip the first 32 bytes of the `hs_ed25519_secret_key` when parsing in `pkg/okey`. It would be nice to check that this initial metadata is not malformed.
Maybe a good place to start looking for inspiration: https://gitlab.torproject.org/tpo/core/tor/-/blob/main/src/feature/keymgt/loadkey.c#L379https://gitlab.torproject.org/tpo/core/arti/-/issues/609Implement octal escapes in PT parsing (or change the spec)2023-11-15T19:04:25ZetaImplement octal escapes in PT parsing (or change the spec)The pluggable transport spec states that some strings passed from PT to host can be Tor CStrings:
```
The MESSAGE value is a human readable string formatted by the PT. The
<Message> contains the log message which can be a String o...The pluggable transport spec states that some strings passed from PT to host can be Tor CStrings:
```
The MESSAGE value is a human readable string formatted by the PT. The
<Message> contains the log message which can be a String or CString (see
section 2 in control-spec.txt).
```
According to control-spec.txt, a CString can include octal escapes:
```
in a CString, the escapes "\n", "\t", "\r", and the octal escapes
"\0" ... "\377" represent newline, tab, carriage return, and the
256 possible octet values respectively.
```
We currently don't implement this, but maybe we should? (Or, we should change the spec to clarify that you can't use these and simplify that way.)
---
The following discussion from !779 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/779#note_2845450):
> Let's open a ticket for this, and additionally add some kind of a "not implemented" error.
>
> That way if anybody actually uses these escapes, we'll learn about it instead of getting silent miscomputations.Arti: Feature parity with the C implementationhttps://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.https://gitlab.torproject.org/tpo/core/arti/-/issues/617BridgeDescManager should use sleep_wallclock2023-10-10T16:14:55ZIan Jacksoniwj@torproject.orgBridgeDescManager should use sleep_wallclockSee https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850268 et prec.See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850268 et prec.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org2022-12-31https://gitlab.torproject.org/tpo/core/arti/-/issues/618BridgeDescManager should use SharedMutArc internally2023-01-24T17:28:59ZIan Jacksoniwj@torproject.orgBridgeDescManager should use SharedMutArc internallyBut SharedMutArc needs to be changed first to not contain `Option`.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850187But SharedMutArc needs to be changed first to not contain `Option`.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850187Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org2022-12-31https://gitlab.torproject.org/tpo/core/arti/-/issues/615SignatureGated API does not enforce semantically-correct use2022-11-01T17:27:00ZIan Jacksoniwj@torproject.orgSignatureGated API does not enforce semantically-correct useWhen cryptographic signatures are in use, it is necessary for the verifier to know what key they expect a document to be signed by. Usually, this is some other key than one contained within the document (ie, for most security purposes, ...When cryptographic signatures are in use, it is necessary for the verifier to know what key they expect a document to be signed by. Usually, this is some other key than one contained within the document (ie, for most security purposes, a self-signature is not very interesting).
Crypto APIs should be designed so that they encourage correct use and so that incorrect (insecure) use is difficult to do by accident.
`SignatureGated` has an innocently-named `check_signature` method which takes no indication of the public key(s) to use. It performs a self-signature check. This invites a mistake where a programmer who has a `SignatureGated` calls `check_signature` expecting it to check it against some ambient idea of what we ought to be trusting (eg, the directory authorities maybe).
Given the nontrivial trust relationships in the Tor network, fixing this is going to involve inspecting call sites etc. This is definitely a task for a rainy day.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/40013torsocks doesn't work on Mac OS Monterey and higher2023-12-12T18:35:34ZXnDY1torsocks doesn't work on Mac OS Monterey and higherI installed Torsocks 2.3.0 via homebrew, while it could not work properly.
I also compiled torsocks myself with gnu gcc (with 0001-Fix-macros-for-accept4-2.patch). The binary looked good but still didn't working.
By contrast, I can con...I installed Torsocks 2.3.0 via homebrew, while it could not work properly.
I also compiled torsocks myself with gnu gcc (with 0001-Fix-macros-for-accept4-2.patch). The binary looked good but still didn't working.
By contrast, I can confirm the latest `proxychains-ng` works, looks like new DYLD hooking method for OSX Monterey is required for recent Mac OS (https://github.com/rofl0r/proxychains-ng/commit/4a013fe6a59ed30e045301dc636d07a6ed999081)
There's some relative discuss: https://tor.stackexchange.com/questions/23135/torsocks-doesn-t-torify-on-macos
Can someone take a look?https://gitlab.torproject.org/tpo/onion-services/sauteed-onions/web/-/issues/3Link WPES slides2022-11-07T11:48:56ZRasmus Dahlbergrasmus@rgdd.seLink WPES slidesLink WPES pdf slides from Paul somewhere.Link WPES pdf slides from Paul somewhere.https://gitlab.torproject.org/tpo/core/tor/-/issues/40711Tor with new ipv6 only works after a restart2022-12-16T18:26:07ZGusTor with new ipv6 only works after a restartA relay operator reported that every day their relay changes the IPv4 and IPv6 addresses. But while Tor with IPv4 works automatically, for IPv6 connection, they need to restart the service.
```
Auto-discovered IPv6 address [1111:::ffff]...A relay operator reported that every day their relay changes the IPv4 and IPv6 addresses. But while Tor with IPv4 works automatically, for IPv6 connection, they need to restart the service.
```
Auto-discovered IPv6 address [1111:::ffff]:9001 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds])
```
#### Tor version
0.4.7.10.
#### torrc
```
SocksPort 0
Log notice file /var/log/tor/notices.log
DataDirectory /var/lib/tor
ControlPort xxxxx
HashedControlPassword xxxxx
ORPort 9001
Nickname justme
RelayBandwidthRate 250 KB # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 750 KB # But allow bursts up to 200KB/s (1600Kbps)
ContactInfo me@there.net
DirPort 9005
ExitRelay 0
ExitPolicy reject *:* # no exits allowed
```
#### Forum link
https://forum.torproject.net/t/ipv6-with-dynamic-prefix-behind-nat/5296