Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-10-24T20:47:55Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40582No clear message in logs when obfs4proxy is missing2022-10-24T20:47:55Zmontoner0No clear message in logs when obfs4proxy is missing### Summary
If for some reason the obfs4proxy executable is missing there's no log entries about it. I've spent a couple of days trying to figure out what's happening and why nothing works.
### Steps to reproduce:
1. apt install tor
...### Summary
If for some reason the obfs4proxy executable is missing there's no log entries about it. I've spent a couple of days trying to figure out what's happening and why nothing works.
### Steps to reproduce:
1. apt install tor
1. Configure obfs4 bridge in config
1. Enable notice level log
1. Try to use Tor
### What is the current bug behavior?
Tor doesn't work, no clues in the log about what's happening.
### What is the expected behavior?
Some error or warning messages about missing executable.
### Environment
- Tor 0.4.5.10
- Debian 11
- apt
### Relevant logs and/or screenshots
### Possible fixesTor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40580start requiring TLS 1.3 support2022-10-24T20:47:54Zdynstart requiring TLS 1.3 support### Background
Any relay without TLS 1.3 is probably using an EOL version of OpenSSL.
1.1.0 support ended upstream in September 2019, one year after 1.1.1 was released. Debian stretch, the last Debian release to package [openssl 1.1.0]...### Background
Any relay without TLS 1.3 is probably using an EOL version of OpenSSL.
1.1.0 support ended upstream in September 2019, one year after 1.1.1 was released. Debian stretch, the last Debian release to package [openssl 1.1.0](https://packages.debian.org/source/stretch/openssl), will hit EOL [on 30 June 2022](https://wiki.debian.org/LTS). (The most recent security patch was on [26 Sep 2021](https://tracker.debian.org/news/1261757/accepted-openssl-110l-1deb9u4-source-amd64-all-into-oldoldstable/) for [DLA-2766-1](https://www.debian.org/lts/security/2021/dla-2766).)
CentOS 7 still ships [a very old version of OpenSSL](https://centos.pkgs.org/7/centos-updates-x86_64/openssl-libs-1.0.2k-24.el7_9.x86_64.rpm.html), and is not EOL until 2024, but it also ships [much more recent versions of NSS](https://centos.pkgs.org/7/centos-updates-x86_64/nss-3.67.0-4.el7_9.x86_64.rpm.html), which unlike OpenSSL 1.0.2, do have TLS 1.3 support.
The one bug that could make TLS 1.3 unuseable, #28973 (openssl issue 7712), has been fixed since 1.1.1b (`Revert "Reduce stack usage in tls13_hkdf_expand"`):
https://github.com/openssl/openssl/commits/OpenSSL_1_1_1b/ssl/tls13_enc.c
### What to change
Now that it's 2022, it should be safe not only to do #28977 but to also:
* `if (!isServer) SSL_set_min_proto_version(result->ssl, TLS1_3_VERSION);`
* delist relays from the consensus if they can't negotiate TLS 1.3,
* but continue to allow TLS 1.2 connections from older clients for now.
### Impact
This change will make TLS 1.2 support optional for clients, so a client like arti can statically link `rustls` with the `tls12` feature disabled at compile-time, reducing its code footprint.
RPM packages targeting CentOS 7 may have to be configured with `--enable-nss` to support TLS 1.3 and operate as a relay.https://gitlab.torproject.org/tpo/core/tor/-/issues/40547tor consumes 100% CPU on connection problems2022-10-24T20:47:50ZL29Ahtor consumes 100% CPU on connection problems### Summary
I had flaky wifi connection on my laptop and tor process started consuming all the available CPU cycles.
### What is the expected behavior?
No excessive CPU consumption.
### Environment
Tor version 0.4.6.9.
Tor is running...### Summary
I had flaky wifi connection on my laptop and tor process started consuming all the available CPU cycles.
### What is the expected behavior?
No excessive CPU consumption.
### Environment
Tor version 0.4.6.9.
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1m, Zlib 1.2.11, Liblzma N/A, Libzstd N/A and Glibc 2.34 as libc.
Tor compiled with GCC version 11.2.1
Gentoo GNU/Linux, distro package.
### Relevant logs and/or screenshots
Nothing relevant in the logs. Top of `perf` analysis shows:
```
# Samples: 47K of event 'cycles'
# Event count (approx.): 41889314041
#
# Children Self Command Shared Object Symbol
# ........ ........ ....... ................ ......................................................
#
64.11% 0.00% tor [unknown] [.] 0xffffffff00000000
|
---0xffffffff00000000
|
|--53.43%--circuit_stream_is_being_handled
|
|--8.67%--circuit_get_global_list
|
--0.84%--ap_stream_wants_exit_attention
57.97% 53.35% tor tor [.] circuit_stream_is_being_handled
|
|--53.22%--0xffffffff00000000
| |
| |--48.82%--circuit_stream_is_being_handled
| |
| --4.26%--circuit_get_global_list
|
--4.61%--circuit_stream_is_being_handled
13.06% 8.78% tor tor [.] circuit_get_global_list
|
|--8.76%--0xffffffff00000000
| |
| |--4.40%--circuit_get_global_list
| |
| --4.36%--circuit_stream_is_being_handled
|
--4.28%--circuit_get_global_list
7.51% 0.00% tor [unknown] [.] 0000000000000000
|
---0
|
|--2.02%--siphash24
|
|--1.38%--routerset_contains2
|
|--0.92%--__strlen_avx2
|
--0.66%--0x5606e555d750
0x100000000c
6.49% 0.00% tor [unknown] [.] 0x00007ffe26cb0110
|
---0x7ffe26cb0110
|
|--4.02%--__vfprintf_internal
|
|--1.22%--__strchrnul_avx2
|
--0.67%--_IO_default_xsputn
```
The complete report is attached: [perf.report](/uploads/eaf7949ea6a2d62e92f93708a3b4c178/perf.report)
### Possible fixeshttps://gitlab.torproject.org/tpo/core/tor/-/issues/40543Onion Service dies randomly after ~1-5 days2022-10-24T20:47:49ZmaqpOnion Service dies randomly after ~1-5 days### Summary
Creating an Onion Service with Stem seems stays up randomly for approximately 1-5 days, it then goes permanently down.
### Steps to reproduce:
1. Use Tor+Stem+Flask to start an ephemeral Onion Service web server
2. Wait ...### Summary
Creating an Onion Service with Stem seems stays up randomly for approximately 1-5 days, it then goes permanently down.
### Steps to reproduce:
1. Use Tor+Stem+Flask to start an ephemeral Onion Service web server
2. Wait up to 5 days
3. See that at some point it's no longer possible to connect to the Onion Service
I wrote a [script](https://gist.github.com/maqp/0e5dcf542ebb97baf98d198115e931ea) that reproduces the issue, but as per the current discussion on `tor-talk` mailing list [Tor users from Finland jumped from 25 000 to 200 000], the script may have had an unintentional side-effect of creating new users, so running the script as it is, may mess up metrics graphs. Thus it definitely needs review (and most likely revision) before use.
### What is the current bug behavior?
Onion Service goes down unpredictably and does not recover.
### What is the expected behavior?
Onion Service stays up until it's turned off by the host.
### Environment
OS
- Ubuntu 21.04
- Lubuntu 21.04
Tor
- Tor version: 0.4.5.6
- Tor install method: APT
Stem
- Stem version: 1.8.0
- Stem install method: PIP
### Relevant logs and/or screenshots:
Below are the logs from two instances of the bug-reproducing script. As the delay before the service goes permanently down is random, I had the script collect data about the server up-times. Note that the timestamp of `Main: Client reports` line is intentionally always one hour after the associated `server last seen` timestamp.
The two interesting things here are, the Onion Service stays up randomly for 1..5 days. Since it's more or less random, it's hard to be sure about the range. The more interesting thing here is the "server last seen" timestamps seem to be often on the hour, but not always (I didn't test against general online connectivity so it's hard to say if those anomalies are related to DSL availability)
Test instance 1
18-12-21 22:02:02 - Main: Starting bug testing.
20-12-21 01:00:52 - Main: Client reports
Server first seen : 18-12-21 22:02:10
Server last seen : 20-12-21 00:00:00
Server's been down for : 01h 00m 37.7s
Restarting with new Onion Service
21-12-21 04:02:10 - Main: Client reports
Server first seen : 20-12-21 01:01:02
Server last seen : 21-12-21 03:00:02
Server's been down for : 01h 00m 06.6s
Restarting with new Onion Service
26-12-21 16:01:15 - Main: Client reports
Server first seen : 21-12-21 04:02:18
Server last seen : 26-12-21 15:00:00
Server's been down for : 01h 00m 02.3s
Restarting with new Onion Service
27-12-21 18:42:49 - Main: Client reports
Server first seen : 26-12-21 16:01:22
Server last seen : 27-12-21 17:40:43
Server's been down for : 01h 00m 04.2s
Restarting with new Onion Service
28-12-21 22:01:05 - Main: Client reports
Server first seen : 27-12-21 18:42:56
Server last seen : 28-12-21 21:00:00
Server's been down for : 01h 00m 01.6s
Restarting with new Onion Service
30-12-21 01:01:20 - Main: Client reports
Server first seen : 28-12-21 22:01:11
Server last seen : 30-12-21 00:00:00
Server's been down for : 01h 00m 02.7s
Restarting with new Onion Service
31-12-21 03:18:37 - Main: Client reports
Server first seen : 30-12-21 01:01:27
Server last seen : 31-12-21 02:18:24
Server's been down for : 01h 00m 06.3s
Restarting with new Onion Service
05-01-22 17:01:00 - Main: Client reports
Server first seen : 31-12-21 03:18:55
Server last seen : 05-01-22 16:00:00
Server's been down for : 01h 00m 04.2s
Restarting with new Onion Service
06-01-22 20:00:58 - Main: Client reports
Server first seen : 05-01-22 17:01:07
Server last seen : 06-01-22 19:00:01
Server's been down for : 01h 00m 21.0s
Restarting with new Onion Service
08-01-22 00:00:33 - Main: Client reports
Server first seen : 06-01-22 20:01:15
Server last seen : 07-01-22 23:00:00
Server's been down for : 01h 00m 16.7s
Restarting with new Onion Service
09-01-22 03:00:56 - Main: Client reports
Server first seen : 08-01-22 00:00:45
Server last seen : 09-01-22 02:00:01
Server's been down for : 01h 00m 03.4s
Restarting with new Onion Service
---
Test instance 2
18-12-21 22:02:03 - Main: Starting bug testing.
20-12-21 01:00:24 - Main: Client reports
Server first seen : 18-12-21 22:02:14
Server last seen : 20-12-21 00:00:00
Server's been down for : 01h 00m 03.1s
Restarting with new Onion Service
21-12-21 04:00:45 - Main: Client reports
Server first seen : 20-12-21 01:00:33
Server last seen : 21-12-21 03:00:01
Server's been down for : 01h 00m 02.7s
Restarting with new Onion Service
26-12-21 16:00:41 - Main: Client reports
Server first seen : 21-12-21 04:00:57
Server last seen : 26-12-21 15:00:01
Server's been down for : 01h 00m 06.1s
Restarting with new Onion Service
27-12-21 19:17:31 - Main: Client reports
Server first seen : 26-12-21 16:00:51
Server last seen : 27-12-21 17:57:09
Server's been down for : 01h 01m 40.2s
Restarting with new Onion Service
28-12-21 23:00:48 - Main: Client reports
Server first seen : 27-12-21 19:17:41
Server last seen : 28-12-21 22:00:00
Server's been down for : 01h 00m 02.2s
Restarting with new Onion Service
30-12-21 02:02:41 - Main: Client reports
Server first seen : 28-12-21 23:00:57
Server last seen : 30-12-21 01:00:01
Server's been down for : 01h 01m 32.1s
Restarting with new Onion Service
31-12-21 17:14:59 - Main: Client reports
Server first seen : 30-12-21 02:02:50
Server last seen : 31-12-21 16:13:50
Server's been down for : 01h 00m 55.9s
Restarting with new Onion Service
01-01-22 20:01:21 - Main: Client reports
Server first seen : 31-12-21 17:15:31
Server last seen : 01-01-22 19:00:02
Server's been down for : 01h 00m 25.6s
Restarting with new Onion Service
02-01-22 23:01:32 - Main: Client reports
Server first seen : 01-01-22 20:01:54
Server last seen : 02-01-22 22:00:03
Server's been down for : 01h 00m 46.2s
Restarting with new Onion Service
04-01-22 02:01:17 - Main: Client reports
Server first seen : 02-01-22 23:01:44
Server last seen : 04-01-22 01:00:00
Server's been down for : 01h 00m 27.1s
Restarting with new Onion Service
05-01-22 05:01:01 - Main: Client reports
Server first seen : 04-01-22 02:01:31
Server last seen : 05-01-22 04:00:00
Server's been down for : 01h 00m 24.5s
Restarting with new Onion Service
10-01-22 17:02:04 - Main: Client reports
Server first seen : 05-01-22 05:01:12
Server last seen : 10-01-22 16:00:03
Server's been down for : 01h 00m 15.1s
Restarting with new Onion Service
11-01-22 20:01:28 - Main: Client reports
Server first seen : 10-01-22 17:02:16
Server last seen : 11-01-22 19:00:00
Server's been down for : 01h 01m 04.7s
Restarting with new Onion Service
12-01-22 23:02:50 - Main: Client reports
Server first seen : 11-01-22 20:02:08
Server last seen : 12-01-22 22:00:40
Server's been down for : 01h 00m 49.0s
Restarting with new Onion Service
### Possible fixes:
No idea, this might be a bug with Tor core, or it might have something to do with Stem.https://gitlab.torproject.org/tpo/core/tor/-/issues/40542scalarmult failed, bad pubkey warning2022-10-24T20:47:48Ziproutescalarmult failed, bad pubkey warninghello. haven't found much information related to these warnings so a kind person on irc told me to open an issue.
linux kernel 5.4.80, tor 0.4.6.7 built from source, non exit relay, uptime 73 days, not hosting HS, not using SocksPort, f...hello. haven't found much information related to these warnings so a kind person on irc told me to open an issue.
linux kernel 5.4.80, tor 0.4.6.7 built from source, non exit relay, uptime 73 days, not hosting HS, not using SocksPort, flags: fast running stable valid
```
Jan 12 07:28:33.000 [warn] ed25519 group order scalarmult failed
Jan 12 07:28:33.000 [warn] Service address [scrubbed] has bad pubkey .
Jan 12 07:28:33.000 [warn] Invalid onion hostname [scrubbed]; rejecting
```
no idea why this might be happening and if it could be somebody trying something. sorry, no debug logging enabled.https://gitlab.torproject.org/tpo/core/tor/-/issues/40541non fixed CircuitStreamTimeout2022-10-24T20:47:48ZpseudonymisaTornon fixed CircuitStreamTimeoutadds a second per retry before falling back to long 15 seconds timeout. instead using fixed CircuitStreamTimeout timeout.
[SmartCircuitStreamTimeout.patch](/uploads/ffa770491a177a82c83e93b324c70407/SmartCircuitStreamTimeout.patch)
Ano...adds a second per retry before falling back to long 15 seconds timeout. instead using fixed CircuitStreamTimeout timeout.
[SmartCircuitStreamTimeout.patch](/uploads/ffa770491a177a82c83e93b324c70407/SmartCircuitStreamTimeout.patch)
Another Idea is use of Exponential backoff timeout instead fixed.
Until best solution implemented, which could be adaptive CircuitStreamTimeout just like CircuitBuildTimeout nowadays.
All allow lower default CircuitStreamTimeout.https://gitlab.torproject.org/tpo/core/tor/-/issues/40538Resolve TROVE-2021-0092023-05-23T20:49:27ZNick MathewsonResolve TROVE-2021-009This is the public issue for TROVE-2021-009.This is the public issue for TROVE-2021-009.https://gitlab.torproject.org/tpo/core/tor/-/issues/40537Recovery after no space left on device2022-10-24T20:47:46ZVortRecovery after no space left on deviceToday one of my programs accidentally used all space on disk, where Tor data is located.
I freed some space later, but it looks like Tor did not fully recovered from this event.
It still complains about consensus diffs and `diff-cach...Today one of my programs accidentally used all space on disk, where Tor data is located.
I freed some space later, but it looks like Tor did not fully recovered from this event.
It still complains about consensus diffs and `diff-cache` directory is not updating.
I think Tor needs special code to recover its mechanisms after disk space becomes available again.
Maybe I did not waited long enough to see it in action.
_(**upd.** After 3 days of complaining in logs, relay finally fixed itself. Probably because I tried to make connection through it. It is good that such recovery is possible, but maybe it needs to be faster)_
But anyway here is the thing which may be fixed anyway:
Logs becomes flooded with messages
`Jan 09 07:16:58.000 [warn] Error writing to "d:\Tor\Data\cached-descriptors.new": No space left on device`
`Jan 09 07:16:58.000 [warn] Unable to store router descriptor`
280 of them actually.
I know that Tor have methods to reduce such duplication, so it should be used if it is possible.
Version: 0.4.6.8https://gitlab.torproject.org/tpo/core/tor/-/issues/40534slow/process/callbacks on Android often quits with error but no message2023-05-30T18:38:18Zeighthaveslow/process/callbacks on Android often quits with error but no messageThere is an intermittent but frequent problem when running the test on Android in GitLab CI. `test-slow` quits with an error but outputs no message:
https://gitlab.com/eighthave/tor-android/-/jobs/1905373288
```console
$ adb -e shell "...There is an intermittent but frequent problem when running the test on Android in GitLab CI. `test-slow` quits with an error but outputs no message:
https://gitlab.com/eighthave/tor-android/-/jobs/1905373288
```console
$ adb -e shell "cd /data/local/tmp; ./$f"'; echo -n $? > '"$f.result";
test-slow
external/test/x86_64/test-slow: 1 file pushed, 0 skipped. 26.3 MB/s (8254824 bytes in 0.299s)
WARNING: linker: ./test-slow: unused DT entry: type 0x6ffffef5 arg 0x8bf18
WARNING: linker: ./test-slow: unused DT entry: type 0x6ffffffe arg 0xbb56c
WARNING: linker: ./test-slow: unused DT entry: type 0x6fffffff arg 0x2
slow/crypto/s2k_rfc2440: OK
slow/crypto/s2k_pbkdf2: OK
slow/crypto/s2k_rfc2440_general: OK
slow/crypto/s2k_rfc2440_legacy: OK
slow/crypto/s2k_errors: OK
slow/crypto/scrypt_vectors: SKIPPED
slow/crypto/pbkdf2_vectors: OK
slow/crypto/pwbox: OK
slow/crypto/fuzz_donna/ed25519_donna: [forking] OK
slow/crypto/fuzz_donna/ed25519_ref10: [forking] OK
slow/process/callbacks:
$
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40512When using UseMiddleNodes or UseEntryNodes, Tor gets stuck2022-10-24T20:47:45ZNeel Chauhanneel@neelc.orgWhen using UseMiddleNodes or UseEntryNodes, Tor gets stuckWhen using `UseMiddleNodes`, I am stuck at these log lines:
Nov 07 12:29:20.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more descriptors: we have 0/2, and can only build 0% of l...When using `UseMiddleNodes`, I am stuck at these log lines:
Nov 07 12:29:20.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more descriptors: we have 0/2, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
Nov 07 12:29:20.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more descriptors: we have 0/2, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
Nov 07 12:29:20.000 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
Nov 07 12:29:21.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.
On `UseEntryNodes`, I am stuck here:
Nov 07 12:36:27.000 [notice] Bootstrapped 0% (starting): Starting
Nov 07 12:36:29.000 [notice] Starting with guard context "default"
These are on middle-only nodes, specifically https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF7C0CFF5497B2 and https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48EF53F812C40D
This does not happen with other relays.
I need to do experiments on the above nodes mainly to help debug an latency issue with my ISP (which my ISP keeps denying but I need to prove something to them).https://gitlab.torproject.org/tpo/core/tor/-/issues/40492Dealing with non-compliant protocol messages2023-01-11T13:31:09ZJaymDealing with non-compliant protocol messages### Summary
While discussing #40400 on irc/matrix with @nickm, we thought it might be good to have a ticket discussing potential protocol extensions that would help track down reasons behind non-compliant protocol messages.
As of the c...### Summary
While discussing #40400 on irc/matrix with @nickm, we thought it might be good to have a ticket discussing potential protocol extensions that would help track down reasons behind non-compliant protocol messages.
As of the current situation, #40400 and the related merge request deal with improving the logging system:
- making ProtocolWarnings less noisy (e.g., rate-limiting or downgrading to info or debug)
- adding a periodic Heartbeat message that logs further information about the misbehaved circuits (e.g., the circuit lifetime)
Protocol level extensions could be useful to fetch/share the nodes' view of the circuit and could complement the periodic Heartbeat message. The main interest would be to help into distinguishing between 1) bugs, 2) bugged byzantine client/relays, 3) actively malicious client/relay with information report from one endpoint. The main problem would be to avoid sharing any too sensitive information.
### A first simple idea
An echo/echo-response type of protocol may help in exchanging/getting more information when an abnormal protocol state is detected. Upon receiving a RELAY-level protocol echo, the node (endpoint) may log information or/and echo back some information to the other endpoint. Those questions yet remain:
- What to exchange/get from the peer?
- What to log on the endpoints?
- What to do if in answer to an echo message we get a non-compliant protocol message.
- Among information which we may think could help, what is safe to exchange?https://gitlab.torproject.org/tpo/core/tor/-/issues/40466Add ExcludeGuardNodes and ExcludeMiddleNodes options2022-10-24T20:47:42ZNeel Chauhanneel@neelc.orgAdd ExcludeGuardNodes and ExcludeMiddleNodes optionsSimilar to the `ExcludeExitNodes` we have right now, we should add an `ExcludeGuardNodes` and `ExcludeMiddleNodes` for guard and middle node selection respectively.Similar to the `ExcludeExitNodes` we have right now, we should add an `ExcludeGuardNodes` and `ExcludeMiddleNodes` for guard and middle node selection respectively.Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40459Bridge-Relay HOWTO wiki update for distros with apparmor, escalade log level ...2022-10-24T20:47:43Zs7rBridge-Relay HOWTO wiki update for distros with apparmor, escalade log level when transport plugin process is killedThe bridge howto wiki instructions we currently have will not apply in Debian Buster or Bullseye (because of apparmor, and I assume the effect is the same on any distro with apparmor enabled).
Basically, the package Tor from deb.torproj...The bridge howto wiki instructions we currently have will not apply in Debian Buster or Bullseye (because of apparmor, and I assume the effect is the same on any distro with apparmor enabled).
Basically, the package Tor from deb.torproject.org comes with apparmor settings in `/etc/apparmor.d/abstractions/tor` that includes `/usr/bin/obfs4proxy Pix,` , but in case obfs4proxy executable is installed at a different path, it won't work:
audit[2994]: AVC apparmor="DENIED" operation="exec" profile="system_tor" name="/usr/local/bin/obfs4proxy" pid=2994 comm="tor" requested_mask="x" denied_mask="x" fsuid=107 ouid=0
kernel: audit: type=1400 audit(1630685584.124:19): apparmor="DENIED" operation="exec" profile="system_tor" name="/usr/local/bin/obfs4proxy" pid=2994 comm="tor" requested_mask="x" denied_mask="x" >
Also, Tor will not complain about it in the log if set to default `notice` level. If you switch to `info` :
[info] process_exec(): Starting new process: /usr/local/bin/obfs4proxy
[info] launch_managed_proxy(): Managed proxy at '/usr/local/bin/obfs4proxy' has spawned with PID '1856'.
These should be set to `warn` level I guess?
The simple fix is to edit `/etc/apparmor.d/abstractions/tor` and add/edit the obfs4proxy path if different from `/usr/bin/obfs4proxy` (which is the default) and reload apparmor service. We should add this extra step in the bridge relay wiki howto and explain that it is necessary if the pluggable transport is installed in a different path than `/usr/bin/$transport` in addition to the libcap2-bin step and `NoNewPrivileges=no` step in `tor@default.service` and `tor@.service`.https://gitlab.torproject.org/tpo/core/tor/-/issues/40454IPv6 Reachability Test Fails on FreeBSD and CenturyLink IPv62022-10-24T20:48:18ZNeel Chauhanneel@neelc.orgIPv6 Reachability Test Fails on FreeBSD and CenturyLink IPv6When I run a dual-stack Tor relay on FreeBSD, and use certain ISPs like CenturyLink, I get a warning with the IPv6 reachability test:
Aug 26 13:18:29.000 [notice] Now checking whether IPv6 ORPort [REDACTED]:143 is reachable... (this...When I run a dual-stack Tor relay on FreeBSD, and use certain ISPs like CenturyLink, I get a warning with the IPv6 reachability test:
Aug 26 13:18:29.000 [notice] Now checking whether IPv6 ORPort [REDACTED]:143 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Aug 26 13:21:31.000 [notice] Self-testing indicates your ORPort 1REDACTED:143 is reachable from the outside. Excellent.
Aug 26 13:23:32.000 [notice] Performing bandwidth self-test...done.
Aug 26 13:36:29.000 [notice] Auto-discovered IPv6 address [REDACTED]:143 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address.
I am able to reach the IPv6 address and port from a VPS.
CenturyLink uses 6rd for IPv6. I could use Comcast, but it's not an option for me (despite being available) since they don't offer symmetrical speeds and cost a lot more, especially since CL gives me fiber and not slow DSL which is good for relays :-).
Google Fiber/Webpass does not have this issue (despite the same `torrc`) since Webpass has native v6, but they aren't in my new address.https://gitlab.torproject.org/tpo/core/tor/-/issues/40449Bridge Authority never assigns a Stable flag to bridges2022-12-01T20:55:48ZCecylia BocovichBridge Authority never assigns a Stable flag to bridgesI found out about this behaviour in https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/33493
Apparently the Bridge Authority hasn't been assigning a Stable flag to bridges for quite some time. I'm not sure wh...I found out about this behaviour in https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/33493
Apparently the Bridge Authority hasn't been assigning a Stable flag to bridges for quite some time. I'm not sure whether this is on purpose or a bug.
torrc file (with IPs and contact info scrubbed):
```
SocksPort 0
Log notice file /var/log/tor-notice.log
#Log info file /var/log/tor-info.log
RunAsDaemon 1
DataDirectory /var/tor
Address [scrubbed]
ORPort [scrubbed]
ORPort [scrubbed]
OutboundBindAddress [scrubbed]
DirPort [scrubbed]
Nickname Serge
RelayBandwidthRate 5500 KBytes
RelayBandwidthBurst 6500 KBytes
User _tor
ExitPolicy reject *:*
ExitPolicy reject6 *:*
PublishServerDescriptor 1
HeartbeatPeriod 1 hours
AvoidDiskWrites 1
NumCPUs 4
ContactInfo [scrubbed]
AuthoritativeDirectory 1
BridgeAuthoritativeDir 1
AuthDirHasIPv6Connectivity 1
EntryStatistics 1
DirReqStatistics 1
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40353dannenberg won't handshake for some people, maybe because of LibreSSL2023-02-07T10:19:46ZRoger Dingledinedannenberg won't handshake for some people, maybe because of LibreSSLIf you look at the bottom of https://consensus-health.torproject.org/#relayinfo and put in 'dannenberg' and click load, right now you will find that moria1, dannenberg, faravahar, and bastet think that dannenberg is Running, but the rest...If you look at the bottom of https://consensus-health.torproject.org/#relayinfo and put in 'dannenberg' and click load, right now you will find that moria1, dannenberg, faravahar, and bastet think that dannenberg is Running, but the rest of the dir auths think it isn't Running.
My laptop, running Debian stable and Tor git master, is unable to connect to it:
```
$ src/app/tor usebridges 1 bridge 193.23.244.244:443
Mar 24 17:48:32.903 [notice] Tor 0.4.6.1-alpha-dev (git-f6af8e2021179498) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd N/A and Glibc 2.28 as libc.
[...]
Mar 24 17:48:36.253 [notice] Delaying directory fetches: No running bridges
Mar 24 17:48:37.257 [notice] Bootstrapped 5% (conn): Connecting to a relay
Mar 24 17:48:37.355 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Mar 24 17:48:37.560 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Mar 24 17:53:01.016 [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (IOERROR; IOERROR; count 1; recommendation warn; host 0000000000000000000000000000000000000000 at 193.23.244.244:443)
Mar 24 17:53:01.016 [warn] 1 connections have failed:
Mar 24 17:53:01.016 [warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
Mar 24 17:57:01.959 [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (IOERROR; IOERROR; count 2; recommendation warn; host 0000000000000000000000000000000000000000 at 193.23.244.244:443)
Mar 24 17:57:01.959 [warn] 2 connections have failed:
Mar 24 17:57:01.959 [warn] 2 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
```
And indeed, the ssl-related logs right before the 14% bootstrap mark say
```
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSLv3/TLS read finished [type=4097,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSLv3/TLS write change cipher spec [type=4097,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSLv3/TLS write client certificate [type=4097,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSLv3/TLS write finished [type=4097,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSL negotiation finished successfully [type=32,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_debug_state_callback(): SSL 0x562d60e6ad30 is now in state SSL negotiation finished successfully [type=4098,val=1].
Mar 24 17:48:37.560 [debug] tor_tls_handshake(): After call, 0x562d6188b920 was in state SSL negotiation finished successfully
```
@dgoulet says he can bootstrap with dannenberg, and indeed around half of the dir auths can so it's not super surprising that he can.
It's not an internet routing thing, because my laptop can reach the port just fine and do the TCP handshake just fine.
I had assumed it is related to #40128 but the dannenberg operator believes they are running the fixed version of libressl.
We've had more user support requests than usual for "my relay / bridge says it's not reachable" so I think there is some bug remaining here.
`dannenberg` is on OpenBSD 6.8 with LibreSSL 3.2.2. One hint is that the Andreas gave us is that he found this in the changelog:
> 013: RELIABILITY FIX: February 3, 2021 All architectures
Various interoperability issues and memory leaks were discovered in
libcrypto and libssl.
https://ftp.openbsd.org/pub/OpenBSD/patches/6.8/common/013_libressl.patch.sighttps://gitlab.torproject.org/tpo/core/tor/-/issues/40347Package for architecture armhf (e.g. for raspberry pi)2024-02-07T15:50:05ZJim NewsomePackage for architecture armhf (e.g. for raspberry pi)### Summary
The version of tor being made available to raspbian (e.g. on a raspberry pi 4) is 0.4.2.7-1~d10.buster+1. This appears to be a sufficiently old version to get the "not recommended" flag.
First saw the issue reported on [red...### Summary
The version of tor being made available to raspbian (e.g. on a raspberry pi 4) is 0.4.2.7-1~d10.buster+1. This appears to be a sufficiently old version to get the "not recommended" flag.
First saw the issue reported on [reddit](https://www.reddit.com/r/TOR/comments/m8hht7/tor_relay_in_a_raspberrypie_as_not_recommended/) and was able to repro on my rpi4.
It looks like the raspberry pi's are architecture "armhf", which isn't provided at https://deb.torproject.org/torproject.org. (I realized this partway through writing this up, and that this is hence probably more of a feature request than a bug)
### Steps to reproduce:
Install repo key
```
$ sudo /bin/bash
root@raspberrypi:/home/jnewsome# wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --import
gpg: key EE8CBC9E886DDD89: 83 signatures not checked due to missing keys
gpg: key EE8CBC9E886DDD89: "deb.torproject.org archive signing key" 52 new signatures
gpg: Total number processed: 1
gpg: new signatures: 52
gpg: no ultimately trusted keys found
root@raspberrypi:/home/jnewsome# gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
OK
```
Update repo
```
jnewsome@raspberrypi:~ $ sudo apt update
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Get:3 https://deb.torproject.org/torproject.org buster InRelease [3,524 B]
Get:4 https://deb.torproject.org/torproject.org buster/main Sources [1,250 B]
Fetched 4,774 B in 2s (1,933 B/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
271 packages can be upgraded. Run 'apt list --upgradable' to see them.
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'https://deb.torproject.org/torproject.org buster InRelease' doesn't support architecture 'armhf'
```
^ this last line looks like the problem.
Try installing/updating anyway for good measure:
```
jnewsome@raspberrypi:~ $ apt show tor
Package: tor
Version: 0.4.2.7-1~d10.buster+1
Status: install ok installed
Priority: optional
Section: net
Maintainer: Peter Palfrader <weasel@debian.org>
Installed-Size: 4,217 kB
Depends: libc6 (>= 2.28), libcap2 (>= 1:2.10), libevent-2.1-6 (>= 2.1.8-stable), libgcc1 (>= 1:3.5), liblzma5 (>= 5.1.1alpha+20120614), libssl1.1 (>= 1.1.1), libsystemd0, libzstd1 (>= 1.3.2), zlib1g (>= 1:1.1.4), adduser, lsb-base
Recommends: logrotate, tor-geoipdb, torsocks
Suggests: mixmaster, torbrowser-launcher, socat, tor-arm, apparmor-utils, obfs4proxy
Conflicts: libssl0.9.8 (<< 0.9.8g-9)
Homepage: https://www.torproject.org/
Download-Size: unknown
APT-Manual-Installed: yes
APT-Sources: /var/lib/dpkg/status
Description: anonymizing overlay network for TCP
Tor is a connection-based low-latency anonymous communication system.
.
Clients choose a source-routed path through a set of relays, and
negotiate a "virtual circuit" through the network, in which each relay
knows its predecessor and successor, but no others. Traffic flowing
down the circuit is decrypted at each relay, which reveals the
downstream relay.
.
Basically, Tor provides a distributed network of relays. Users bounce
their TCP streams (web traffic, ftp, ssh, etc) around the relays, and
recipients, observers, and even the relays themselves have difficulty
learning which users connected to which destinations.
.
This package enables only a Tor client by default, but it can also be
configured as a relay and/or a hidden service easily.
.
Client applications can use the Tor network by connecting to the local
socks proxy interface provided by your Tor instance. If the application
itself does not come with socks support, you can use a socks client
such as torsocks.
.
Note that Tor does no protocol cleaning on application traffic. There
is a danger that application protocols and associated programs can be
induced to reveal information about the user. Tor depends on Torbutton
and similar protocol cleaners to solve this problem. For best
protection when web surfing, the Tor Project recommends that you use
the Tor Browser Bundle, a standalone tarball that includes static
builds of Tor, Torbutton, and a modified Firefox that is patched to fix
a variety of privacy bugs.
N: There is 1 additional record. Please use the '-a' switch to see it
jnewsome@raspberrypi:~ $ sudo apt install tor
Reading package lists... Done
Building dependency tree
Reading state information... Done
tor is already the newest version (0.4.2.7-1~d10.buster+1).
The following packages were automatically installed and are no longer required:
alsa-base gstreamer0.10-alsa gstreamer0.10-plugins-base libgstreamer-plugins-base0.10-0
libgstreamer0.10-0 libllvm8 libmicrodns0 libva-wayland2 libxfce4util-bin
libxfce4util-common libxfce4util7 libxfconf-0-2 pimixer point-rpi xfconf
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 271 not upgraded.
```
### What is the current bug behavior?
0.4.2.7 appears to be the newest-available version.
### What is the expected behavior?
It should be the latest production version. It looks like [buster on arm64 is currently getting 0.4.5.7](https://deb.torproject.org/torproject.org/dists/buster/main/binary-arm64/Packages), but maybe this isn't the package list that raspbian ends up getting?
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
0.4.2.7
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
```
$ lsb_release --all
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
$ uname -a
Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux
```
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
apt
### Relevant logs and/or screenshots
### Possible fixeshttps://gitlab.torproject.org/tpo/core/tor/-/issues/40332Heartbeat log unit size are not user-friendly2023-05-25T13:08:33ZcypherpunksHeartbeat log unit size are not user-friendlyIn the file `tor-0.4.5.6/src/feature/dirclient/dirclient.c`, at lines 2002-2005, the heartbeat log message shows different amount of data in bytes.
Exemple:
>>>
[XXX 00 00:00:00.000] [notice] While not bootstrapping, fetched this many...In the file `tor-0.4.5.6/src/feature/dirclient/dirclient.c`, at lines 2002-2005, the heartbeat log message shows different amount of data in bytes.
Exemple:
>>>
[XXX 00 00:00:00.000] [notice] While not bootstrapping, fetched this many bytes: XXXXXXXXX (server descriptor fetch); XXXXXX (server descriptor upload); XXXXXXXX (consensus network-status fetch); XXXX (authority cert fetch); XXXXX (microdescriptor fetch)
>>>
Knowing that my server fetch XXXXXXXXX bytes from the server directory does not really help me to easily understand my bandwidth usage. It could be more nice to look at if each amount of data will be followed by a appropriate unit size. For exemple:
>>>
[Time] [notice] While not bootstrapping, fetched this many data: XX.X `MiB` (server descriptor fetch); XX.X `KiB` (server descriptor upload); XX.X `MiB` (consensus network-status fetch); X.X `KiB` (authority cert fetch); XXX.X `KiB` (microdescriptor fetch)
>>>
And like it is said in the description of the file `core/or/status.c`, from line 4 to 13:
>>>
[...] heartbeat log messages, [...] inform users and operators about basic facts to do with their Tor instance. [...] It collects data [...] and logs it in a **human-readable** format.
>>>https://gitlab.torproject.org/tpo/core/tor/-/issues/40328Man tor - Refactoring - Creation of a new `BANDWIDTH MANAGEMENT OPTIONS` section2023-04-03T16:43:38ZcypherpunksMan tor - Refactoring - Creation of a new `BANDWIDTH MANAGEMENT OPTIONS` sectionA total of 11 options (see the list below) should go in a new section named `BANDWIDTH MANAGEMENT OPTIONS`. This would reduce the amount of time spent scrolling around in the man tor page and make finding options more intuitive instead o...A total of 11 options (see the list below) should go in a new section named `BANDWIDTH MANAGEMENT OPTIONS`. This would reduce the amount of time spent scrolling around in the man tor page and make finding options more intuitive instead of having to remember the spreaded locations were bandwidth options are sometimes located.\\
We could also take this opportunity to change the location of the warning about how bandwidth-limiting options are managed. This warning is located at the end of the description of the option `BandwidthRate`. We could move the warning to the description of the newly created `BANDWIDTH MANAGEMENT OPTIONS` section, or at least, in the `THE CONFIGURATION FILE FORMAT` section.\\
Also, like it is said in description of the option `AccountingMax`:\
>>>
Note that (as also described in the Bandwidth section) Tor uses powers of two [...]
>>>
This "Bandwidth section" does not really exist, but now it will if this issue is approuved. The non-existing "Bandwidth section" seems to refer to the description of the option `BandwidthRate`.\\
I will make the neccessary changes in the man tor page and only show you the final result. You will just need to accept it or tell me what need more tweaking.\\
List of options that will need to move to the newly created one:\
>>>
GENERAL OPTIONS:\
- BandwidthBurst
- BandwidthRate
- CountPrivateBandwidth
- MaxAdvertisedBandwidth
- PerConnBWBurst
- PerConnBWRate
- RelayBandwidthBurst
- RelayBandwidthRate\
SERVER OPTIONS:\
- AccountingMax
- AccountingRule
- AccountingStart
>>>
The newly created section will look something like that:\
>>>
**BANDWIDTH MANAGEMENT OPTIONS**\
Description : The end of the description of the options `BandwidthRate` about size unit format.\\
- AccountingMax
- AccountingRule
- AccountingStart
- BandwidthBurst
- BandwidthRate
- CountPrivateBandwidth
- MaxAdvertisedBandwidth
- PerConnBWBurst
- PerConnBWRate
- RelayBandwidthBurst
- RelayBandwidthRate
>>>\
On an unrelated note to this issue:\
I try to use the functionalities of `GitLab Flavord Markdown` in my previous 2 issues, but that did not really goes has I expected, so sorry for the ugly formating of all my previous issues. I'm learning. I hope this issue look a bit better :)https://gitlab.torproject.org/tpo/core/tor/-/issues/40327Man tor - Refactoring - Creation of a `LOGS OPTIONS` section2023-04-03T16:42:53ZcypherpunksMan tor - Refactoring - Creation of a `LOGS OPTIONS` sectionA total of 13 options (see the list below) are all only related to logs. We should create a new section named `LOGS OPTIONS` and all put them there instead of leaving them in the `GENERAL OPTIONS` and `SERVER OPTIONS` sections.
This wou...A total of 13 options (see the list below) are all only related to logs. We should create a new section named `LOGS OPTIONS` and all put them there instead of leaving them in the `GENERAL OPTIONS` and `SERVER OPTIONS` sections.
This would reduce the amount of scrolling in the man tor page and make finding options more intuitive instead of having to remember the weird location that options descriptions are sometimes located. If this issue is approuved, I will make the necessary changes in the man tor page and only show you the final result. You will only need to accept it or tell me what need more tweaking.
Here is the list of affected options :
>>>
**GENERAL OPTIONS**
Log (x4)
LogMessageDomains
LogTimeGranularity
MaxUnparseableDescSizeToLog
ProtocolWarnings
SafeLogging
SyslogIdentityTag
TruncateLogFile
**SERVER OPTIONS**
HeartbeatPeriod
MainloopStats
>>>
The new `LOGS OPTIONS` section will look something like that :
>>>
**LOGS OPTIONS**
Description of LOGS OPTION : Do we really need it ? It is self-explanatory.
HeartbeatPeriod
Log (x4)
LogMessageDomains
LogTimeGranularity
MainloopStats
MaxUnparseableDescSizeToLog
ProtocolWarnings
SafeLogging
SyslogIdentityTag
TruncateLogFile
>>>