The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:56:05Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22955Specify how PrivCount will work with Tor2020-06-27T13:56:05ZteorSpecify how PrivCount will work with TorPrivCount is an experimental statistics collection protocol, which provides secure aggregation of a differentially private set of statistics.
We need to work out which parts of the experimental protocol are useful, and how they could wo...PrivCount is an experimental statistics collection protocol, which provides secure aggregation of a differentially private set of statistics.
We need to work out which parts of the experimental protocol are useful, and how they could work on tor relays, and provide results to Tor metrics.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22961Should tor-spec say that nodes MUST NOT use TLS compression?2021-08-23T15:17:06ZteorShould tor-spec say that nodes MUST NOT use TLS compression?In general, it's unsafe to compress attacker-controlled data and secret data together in the same blocks, because attackers can use compressed data size to discover the secret (as in the CRIME attack).
Discovered as part of legacy/trac#...In general, it's unsafe to compress attacker-controlled data and secret data together in the same blocks, because attackers can use compressed data size to discover the secret (as in the CRIME attack).
Discovered as part of legacy/trac#22948.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22962Clarify the security severity of issues that make denial of service easier2021-07-22T16:22:40ZteorClarify the security severity of issues that make denial of service easierhttps://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy
In legacy/trac#22948, we discovered that the relay integrity digest was easier to guess than it should be. This makes the following classes of attacks ea...https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy
In legacy/trac#22948, we discovered that the relay integrity digest was easier to guess than it should be. This makes the following classes of attacks easier:
* sending bandwidth and guessing the integrity digest, and
* modifying cells and manipulating the integrity digest.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22963Make relay integrity digests harder to guess by padding cells with random bytes2021-08-23T15:17:06ZteorMake relay integrity digests harder to guess by padding cells with random bytesThe tor spec says we should put random bytes in padding cells:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1534
But we don't currently do this (see legacy/trac#22948).
And we don't put random bytes in other cells.
This...The tor spec says we should put random bytes in padding cells:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1534
But we don't currently do this (see legacy/trac#22948).
And we don't put random bytes in other cells.
This makes it easier to guess the circuit integrity digest, which makes some DoS and malleability attacks easier.
Should we pad all cells with random bytes?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22964Clarify comment about all tor data being encrypted2020-06-27T13:56:05ZteorClarify comment about all tor data being encryptedThis isn't quite accurate:
```
/* Don't actually allow compression; it uses ram and time, but the data
* we transmit is all encrypted anyway. */
```
The following "data" isn't encrypted:
* cell headers
* non-relay cell types
I sug...This isn't quite accurate:
```
/* Don't actually allow compression; it uses ram and time, but the data
* we transmit is all encrypted anyway. */
```
The following "data" isn't encrypted:
* cell headers
* non-relay cell types
I suggest:
```
/* Don't actually allow compression; it uses ram and time, but the
* circuit data we transmit is encrypted anyway. */
```Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22972tor expert bundle only read the first letter from config2020-07-28T03:55:33ZTractor expert bundle only read the first letter from configif i set a config file with command line argument, its looks like tor read only the first letter.
torrc:
SOCKSPort 1234
Output:
Jul 19 02:28:41.488 [notice] Tor 0.3.0.9 (git-22b3bf094e327093) running on Windo
ws 8 [server] with Libeven...if i set a config file with command line argument, its looks like tor read only the first letter.
torrc:
SOCKSPort 1234
Output:
Jul 19 02:28:41.488 [notice] Tor 0.3.0.9 (git-22b3bf094e327093) running on Windo
ws 8 [server] with Libevent 2.0.22-stable, OpenSSL 1.0.2k and Zlib 1.2.8.
Jul 19 02:28:41.491 [notice] Tor can't help you if you use it wrong! Learn how t
o be safe at https://www.torproject.org/download/download#warning
Jul 19 02:28:41.511 [notice] Read configuration file "c:\users\administrator.ll-
dc02\documents\visual studio 2013\Projects\Lissy Cruuv\unbreakable non-server co
munication\bin\Debug\tor\data\torrc".
Jul 19 02:28:41.520 [warn] The abbreviation 'S' is deprecated. Please use 'Socks
SocketsGroupWritable' instead
Jul 19 02:28:41.520 [warn] Path for GeoIPFile (<default>) is relative and will r
esolve to C:\Users\Administrator.LL-DC02\<default>. Is this what you wanted?
Jul 19 02:28:41.520 [warn] Path for GeoIPv6File (<default>) is relative and will
resolve to C:\Users\Administrator.LL-DC02\<default>. Is this what you wanted?
Jul 19 02:28:41.523 [notice] Opening Socks listener on 127.0.0.1:9050
Jul 19 02:28:42.000 [notice] Bootstrapped 0%: Starting
Jul 19 02:28:43.000 [notice] Starting with guard context "default"
Jul 19 02:28:43.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Jul 19 02:28:45.000 [notice] Bootstrapped 85%: Finishing handshake with first ho
p
Jul 19 02:28:45.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jul 19 02:28:45.000 [notice] Tor has successfully opened a circuit. Looks like c
lient functionality is working.
Jul 19 02:28:45.000 [notice] Bootstrapped 100%: Done
**Trac**:
**Username**: lanealucyTor: unspecifiedErinn ClarkErinn Clarkhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22976disallow tor exec'ing2020-06-27T13:56:05Zdawuuddisallow tor exec'ing
Hello from PETS2017. I recently chatted with Nick Mathewson who suggested that it would be very easy to patch tor such that exec'ing programs could optionally be disallowed. Currently there are three torrc config options that can cause ...
Hello from PETS2017. I recently chatted with Nick Mathewson who suggested that it would be very easy to patch tor such that exec'ing programs could optionally be disallowed. Currently there are three torrc config options that can cause tor to exec:
1. PortForwardingHelper
2. ClientTransportPlugin
3. ServerTransportPlugin
Of course these can be used via the control port which is precisely why it was important to the Subgraph OS project to have a decent Tor control port filter; we were mainly concerned with preventing sandbox escapes. I wrote Roflcoptor for this purpose:
https://github.com/subgraph/roflcoptor
A few other projects have also written their own Tor control port filter daemons. I will not list them here. Even with this feature addition to tor, these Tor control port filter daemons will still be useful for limiting the authority delegated by access to the tor control port.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22979prop224: Add an introduction point onion key in the descriptor2020-06-27T13:56:04ZDavid Gouletdgoulet@torproject.orgprop224: Add an introduction point onion key in the descriptorSo it turns out that this menagerie of keys in prop224 was missing yet one more key in it :D.
To extend to an introduction point, we need its onion key meaning we have to add it to the descriptor. Keep in mind that the client does NOT l...So it turns out that this menagerie of keys in prop224 was missing yet one more key in it :D.
To extend to an introduction point, we need its onion key meaning we have to add it to the descriptor. Keep in mind that the client does NOT lookup the node in its consensus in order not to reveal which consensus it's using and avoid reachability issues with different consensus between service and client.
This goes in two fold. First add an onion key field in the spec and then implement it in an extra commit in legacy/trac#20657 code (which is being reviewed). I would like us to avoid making a branch depending on 8k lines of code from another unmerged ticket.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/22987TAP Hybrid Encryption case 1 is used when the payload is equal to the maximum...2020-06-27T13:56:04ZteorTAP Hybrid Encryption case 1 is used when the payload is equal to the maximum lengthThe spec says:
```
- 1. If M is less than PK_ENC_LEN-PK_PAD_LEN, pad and encrypt M with PK.
+ 1. If M is less than or equal to PK_ENC_LEN-PK_PAD_LEN, pad and encrypt M with PK.
```
https://gitweb.torproject.org/torspec.git/tree...The spec says:
```
- 1. If M is less than PK_ENC_LEN-PK_PAD_LEN, pad and encrypt M with PK.
+ 1. If M is less than or equal to PK_ENC_LEN-PK_PAD_LEN, pad and encrypt M with PK.
```
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n117
(We'll need to fix the line wrapping here as well.)
But the code does:
```
if (!force && fromlen+overhead <= pkeylen) {
```
https://gitweb.torproject.org/tor.git/tree/src/common/crypto.c#n1262Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22991Ubuntu/AppArmor 0.3.0.9 and 0.3.1.4-alpha - onion service setup fails2020-06-27T13:56:04ZTracUbuntu/AppArmor 0.3.0.9 and 0.3.1.4-alpha - onion service setup failsAfter setting up new Ubuntu server hosts and adding the Tor Project repo, setting up an onion service fails due to apparmor.
Hosts tested:
Xenial server
Zesty server
Tor versions tested:
0.3.0.9
0.3.1.4-alpha
Errors:
/var/log/kern....After setting up new Ubuntu server hosts and adding the Tor Project repo, setting up an onion service fails due to apparmor.
Hosts tested:
Xenial server
Zesty server
Tor versions tested:
0.3.0.9
0.3.1.4-alpha
Errors:
/var/log/kern.log |grep tor
Jul 20 19:25:58 zesty kernel: [ 50.173406] audit: type=1400 audit(1500578758.127:16): apparmor="DENIED" operation="capable" profile="system_tor" pid=2148 comm="tor" capability=2 capname="dac_read_search"
/var/log/syslog |grep tor
Jul 20 19:26:00 zesty tor[2190]: Jul 20 19:26:00.111 [notice] Tor 0.3.1.4-alpha (git-c3fe257c709bb814) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 20 19:26:00 zesty tor[2190]: Jul 20 19:26:00.112 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 20 19:26:00 zesty tor[2190]: Jul 20 19:26:00.113 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jul 20 19:26:00 zesty tor[2190]: Jul 20 19:26:00.114 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 20 19:26:00 zesty tor[2190]: Jul 20 19:26:00.114 [notice] Read configuration file "/etc/tor/torrc".
Jul 20 19:26:00 zesty tor[2190]: Configuration was valid
Jul 20 19:26:00 zesty tor[2193]: Jul 20 19:26:00.223 [notice] Tor 0.3.1.4-alpha (git-c3fe257c709bb814) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 20 19:26:00 zesty tor[2193]: Jul 20 19:26:00.224 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 20 19:26:00 zesty tor[2193]: Jul 20 19:26:00.225 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jul 20 19:26:00 zesty tor[2193]: Jul 20 19:26:00.225 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 20 19:26:00 zesty tor[2193]: Jul 20 19:26:00.226 [notice] Read configuration file "/etc/tor/torrc".
Jul 20 19:26:00 zesty tor[2193]: Jul 20 19:26:00.233 [warn] Directory /var/lib/tor/hidden_service/ cannot be read: Permission denied
Jul 20 19:26:00 zesty tor[2193]: Jul 20 19:26:00.234 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
Jul 20 19:26:00 zesty tor[2193]: Jul 20 19:26:00.235 [err] Reading config failed--see warnings above.
Jul 20 19:26:00 zesty systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
Jul 20 19:26:00 zesty systemd[1]: tor@default.service: Unit entered failed state.
Jul 20 19:26:00 zesty systemd[1]: tor@default.service: Failed with result 'exit-code'.
Jul 20 19:26:00 zesty systemd[1]: tor@default.service: Service hold-off time over, scheduling restart.
Jul 20 19:26:00 zesty systemd[1]: tor@default.service: Start request repeated too quickly.
Jul 20 19:26:00 zesty systemd[1]: tor@default.service: Unit entered failed state.
Jul 20 19:26:00 zesty systemd[1]: tor@default.service: Failed with result 'exit-code'.
Identified solution:
sudo vim /etc/apparmor.d/abstractions/tor
add this line to capabilities:
capability dac_read_search,
reload:
sudo /etc/init.d/apparmor reload
sudo service tor restart
**Trac**:
**Username**: yawnboxhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22992master pubkey of the hidden service quantum computer resistance2020-07-29T15:49:54ZTracmaster pubkey of the hidden service quantum computer resistance what will be done if quantum computers can compute the private key of the ed25519 master pubkey "of the hidden services". Large-scale/medium scale quantum computers would possibly be able to compute the private key of the master pubkey ... what will be done if quantum computers can compute the private key of the ed25519 master pubkey "of the hidden services". Large-scale/medium scale quantum computers would possibly be able to compute the private key of the master pubkey of the hidden service then they would be able to impersonate the hidden service.
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1901
**Trac**:
**Username**: Dbryrtfbcbhgfhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22993prop224 has two section 0.5s2020-06-27T13:56:04Zteorprop224 has two section 0.5sBoth the table of contents and the sections themselves have this typo:
```
0.5. Assigned relay cell types
0.5. Acknowledgments
```Both the table of contents and the sections themselves have this typo:
```
0.5. Assigned relay cell types
0.5. Acknowledgments
```Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22994Use consistently named constants for relay command specifications2020-07-28T03:56:13ZteorUse consistently named constants for relay command specificationsThe original spec uses RELAY_*:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1257
The onion service specs and code use RELAY_COMMAND_*:
https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n102
https://gitweb.tor...The original spec uses RELAY_*:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1257
The onion service specs and code use RELAY_COMMAND_*:
https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n102
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n252
https://gitweb.torproject.org/tor.git/tree/src/or/or.h#n562
We should probably make these consistent. Eventually.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22995prop224 should say we use SHA3-256 for rend circuit digests2021-07-22T16:22:40Zteorprop224 should say we use SHA3-256 for rend circuit digestsIn prop224, the rend section says:
```
A successfully completed handshake, as embedded in the
INTRODUCE/RENDEZVOUS cells, gives the client and hidden service host
a shared set of keys Kf, Kb, Df, Db, which they use for sending
...In prop224, the rend section says:
```
A successfully completed handshake, as embedded in the
INTRODUCE/RENDEZVOUS cells, gives the client and hidden service host
a shared set of keys Kf, Kb, Df, Db, which they use for sending
end-to-end traffic encryption and authentication as in the regular
Tor relay encryption protocol, applying encryption with these keys
before other encryption, and decrypting with these keys before other
decryption. The client encrypts with Kf and decrypts with Kb; the
service host does the opposite.
```
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1890
But that's not what the code does: circuit_init_cpath_crypto() uses SHA3-256 rather than SHA1 when `is_hs_v3` is true.Tor: 0.3.2.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/22996The router protocol versions section in dir-spec is out of date2021-09-16T14:32:00ZteorThe router protocol versions section in dir-spec is out of dateI doubt clients do this: they only download the consensus, not votes:
```
A client should believe that a router supports a given feature if that
feature is supported by the router or protocol versions in more than half
of the live ...I doubt clients do this: they only download the consensus, not votes:
```
A client should believe that a router supports a given feature if that
feature is supported by the router or protocol versions in more than half
of the live networkstatuses' "v" entries for that router.
```
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3493Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23006Test connection speed2020-07-28T03:56:26ZcypherpunksTest connection speedPlease figure out a way to show what is my internet connection speed between the tor client and the first hop (Guard or bridge).
Suggestion, maybe deduce the speed of downloading the consensus files and display it in the log files.Please figure out a way to show what is my internet connection speed between the tor client and the first hop (Guard or bridge).
Suggestion, maybe deduce the speed of downloading the consensus files and display it in the log files.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23009Make it clear that RELAY_SENDME cells don't have a payload2021-07-22T16:22:26ZteorMake it clear that RELAY_SENDME cells don't have a payloadtor-spec taslks about SENDME cells, but doesn't say if they have a payload or not. We should probably make this explicit:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1560tor-spec taslks about SENDME cells, but doesn't say if they have a payload or not. We should probably make this explicit:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1560Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23010prop224: make sure the protocol handshakes are extensible2022-06-17T17:58:09Zteorprop224: make sure the protocol handshakes are extensibleHow and when do we plan to move away from using SHA1 in Tor circuits?
For non-onion service circuits, this would mean:
* implementing support for circuit digests using a secure hash [0]
* adding a Relay protocol version 3
* teaching cli...How and when do we plan to move away from using SHA1 in Tor circuits?
For non-onion service circuits, this would mean:
* implementing support for circuit digests using a secure hash [0]
* adding a Relay protocol version 3
* teaching clients to use a secure hash [0] digest with relays with Relay protocol >= 3
For onion service circuits, it's more complicated, because the
following circuit types can't use relay versions from the consensus:
* client to intro
* service to rend
* client to service
(Using relay versions from the consensus leaks which consensus clients
and services have, which reduces the anonymity set.)
Here are the upgrade mechanisms in prop224 at the moment, for both
circuit protocol versions and any necessary handshake material:
client to intro:
* the protocol version could be in a proto line to each intro point,
but this isn't implemented yet
* the handshake data can be in the link-specifiers (I think?)
service to rend
* the protocol version could be in the EXT_FIELD in the INTRODUCE
cell, but this isn't implemented yet
* the handshake data can be in the link-specifiers (I think?)
client to service:
* the protocol version is in the create2-formats in the descriptor
* the handshake data is in HANDSHAKE_INFO in the RENDEZVOUS cells
* SHA3-256 digests are implemented, but not documented in prop224 (legacy/trac#22995)
I suggest we make the following changes to prop224 to make this happen:
Protocol version information:
* add the relevant relay protocol versions to the intro point section
of the descriptor
* put the relevant relay protocol versions in an EXT_FIELD in the
INTRODUCE cell
* check create2-formats contains all the version info we will need to
change the client to service circuit protocol version
Downgrade resistance:
* teach clients and services to use the highest common protocol between
client/service and relay, excluding protocols that are below the
minimum required protocol versions
* work out how we will tell clients to no longer accept an old
create2-formats line from a service
[0]: probably SHA3-256, but let's make sure it can be upgraded, because it will be broken some day, toohttps://gitlab.torproject.org/tpo/core/tor/-/issues/23013Tor 0.3.0.9 tarball was missing ReleaseNotes entry2020-07-28T03:56:54ZRoger DingledineTor 0.3.0.9 tarball was missing ReleaseNotes entryhttps://dist.torproject.org/tor-0.3.0.9.tar.gz
has an 0.3.0.9 stanza in the ChangeLog file but not in the ReleaseNotes file.
There's a release checklist:
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/ReleasingTor.md
but it look...https://dist.torproject.org/tor-0.3.0.9.tar.gz
has an 0.3.0.9 stanza in the ChangeLog file but not in the ReleaseNotes file.
There's a release checklist:
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/ReleasingTor.md
but it looks like this step got missed this time.
Are there technical steps we can take to make sure things are synced in future releases, so we don't have to rely only on the checklist?
Like, 'make dist' could check and complain?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23019prop224: Validate received onion addresses on the client side2020-06-27T13:56:03ZGeorge Kadianakisprop224: Validate received onion addresses on the client sideThis is a ticket to remind ourselves that we on the client-side we need to validate onion addresses using the validation routines introduced in legacy/trac#22006.This is a ticket to remind ourselves that we on the client-side we need to validate onion addresses using the validation routines introduced in legacy/trac#22006.Tor: 0.3.2.x-final