The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-01-06T15:55:38Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41068"HTTPS-Only Mode Alert Secure Connection Not Available" gets triggered when l...2023-01-06T15:55:38ZRoger Dingledine"HTTPS-Only Mode Alert Secure Connection Not Available" gets triggered when loading is slow, and it's scaring usersLoad your Tor Browser, then move to a network where Tor can't connect, e.g. because it is firewalled or because you're captive portaled or etc.
Then type a non-existent domain into the url bar (I picked dffffogifdgoise.org) and hit ente...Load your Tor Browser, then move to a network where Tor can't connect, e.g. because it is firewalled or because you're captive portaled or etc.
Then type a non-existent domain into the url bar (I picked dffffogifdgoise.org) and hit enter.
After a few minutes, Tor will give up trying to find a circuit for that domain, and it will give you an error page.
In the old days, we'd get the "We can’t connect to the server at www.dffffogifdgoise.org." error page.
But now (Tor Browser 11.5) we get a new page, telling the user "You've enabled HTTPS-Only Mode for enhanced security, and a HTTPS version of dffffogifdgoise.org is not available." and then "Most likely, the website simply does not support HTTPS."
I'm attaching a screenshot of "I failed to reach news.google.com" which mistakenly/misleadingly turned into the https-only mode warning:
![Screenshot_2022-07-20_22-42-52](/uploads/e36a4ef34e54dc51cd0fe16a9a77787a/Screenshot_2022-07-20_22-42-52.png)https://gitlab.torproject.org/tpo/core/arti/-/issues/874Implement obtaining server descriptors from the live network2023-06-30T14:50:43ZjugaImplement obtaining server descriptors from the live networkWorking on https://gitlab.torproject.org/tpo/network-health/margot/-/issues/13#note_2905118 I realized i can't just change tor client config as I do with [stem](https://stem.torproject.org) and set `UseMicrodescriptors 0` to download the...Working on https://gitlab.torproject.org/tpo/network-health/margot/-/issues/13#note_2905118 I realized i can't just change tor client config as I do with [stem](https://stem.torproject.org) and set `UseMicrodescriptors 0` to download the server descriptors.
@nickm explained to me by irc, it isn't planned to implement that option in arti. However it's currently possible to parse NS consensus, which list server descriptors and parse the descriptors, just tor-dirmgr doesn't invoke something like that.
As he also pointed out, there're a lot of corner cases (retrying failures, caching things, expiring the cache, restarting when the consensus is out-of-date, ...) if we'd implement a quick downloader.
@gk and I think this is an important issue to be able to [move away stem](https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/124) in our tools. @rishadbaniya has just run into the same issue to work on https://gitlab.torproject.org/rishadbaniya/erpc/-/issues/1. @hiro would also need it to replace metrics tools.
Is this feature possible in the next few months or at some point in the future?https://gitlab.torproject.org/tpo/core/tor/-/issues/40777Amend greeting message with pointer to weather.torproject.org2023-04-12T14:48:13ZGeorg KoppenAmend greeting message with pointer to weather.torproject.orgIn `log_new_relay_greeting` we have a welcome message pointing to our lifecycle document:
```
tor_log(LOG_NOTICE, LD_GENERAL, "You are running a new relay. "
"Thanks for helping the Tor network! If you wish to know "
...In `log_new_relay_greeting` we have a welcome message pointing to our lifecycle document:
```
tor_log(LOG_NOTICE, LD_GENERAL, "You are running a new relay. "
"Thanks for helping the Tor network! If you wish to know "
"what will happen in the upcoming weeks regarding its usage, "
"have a look at https://blog.torproject.org/lifecycle-of-a"
"-new-relay");
```
We should amend that message and pointing to our new Tor Weather service at weather.tpo as well offering operators an easy way to get notified e.g. in case their relay goes down.https://gitlab.torproject.org/tpo/community/relays/-/issues/18Write "expectations for relay operators" document2024-03-13T14:32:32ZRoger DingledineWrite "expectations for relay operators" documentMotivated by tpo/web/community#165, we could really use a document for relay operators which sets our expectations for what it means to run a relay properly.
This document would be the mirror image of tpo/network-health/team#11, which a...Motivated by tpo/web/community#165, we could really use a document for relay operators which sets our expectations for what it means to run a relay properly.
This document would be the mirror image of tpo/network-health/team#11, which as I understand it would be the guidelines for the bad-relays team on when a relay should no longer be permitted in the network.
The goal is to make it clear what we expect of relay operators, rather than leaving it implicit.
And with that preface, here is my first draft of five sections of a relay expectations document:
1. Keep users safe:
* Don't look at, or modify, network traffic.
* Don't reveal user or destination IP addresses, or the timing or volume of connections.
* By default (e.g. unless you are debugging a specific thing), log at loglevel "notice", and leave SafeLogging on.
* If you run more than one relay, set the MyFamily option for each of them, to instruct clients to avoid using more than one in a circuit, and to help the network health team know which relays are really yours.
* Don't modify your Tor process to examine internal state. In particular, don't record v2 onion addresses.
* If you want to measure or study the Tor network, do it safely: write up your plan first and get feedback from the Tor Research Safety Board: https://research.torproject.org/safetyboard/
2. Maintain good system op-sec:
* Run a version of Tor that is supported. You can see supported versions on this table: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases
* Watch your Tor logs for warnings and try to address them.
* Make sure to keep the rest of your system software up to date too.
* Try not to let the cops get your relay keys, but if they do, make sure we learn about it so we can block those keys from the network.
3. Make sure your relay isn't broken:
* Tor relays need 10000+ file descriptors, so be sure your Tor package or startup script is raising your ulimit -n.
* Don't firewall outgoing connections. Tor relays need to be able to reach all other Tor relays, including new ones that are self-testing their reachability.
* Exit relays need a working DNS resolver. Also, don't use a DNS resolver that censors its answers.
* If there's a port or address block that your exit relay can't reach, be sure to reject it in your ExitPolicy, so clients can know to use a different exit.
4. Sustainability:
* Don't try to run an exit relay at a place where you plan to just discard it and move on if the ISP complains to you. Running an exit relay involves advocacy to your ISP, to help them understand how Tor works and why it's important.
* If somebody tries to get you to backdoor or tap your relay, don't do it. Find a lawyer and fight it, and if you can't fight it, shut the relay down instead.
5. Be a part of our community:
* Remember that running a relay is an act of transparency (even though being a Tor *user* is an act of privacy), because the way to strengthen trust in relays is by having a stronger community.
* Make an effort to meet other relay operators and developers in your area and at conferences and meetups.
* Be sure to set your ContactInfo to a working address in case we need to reach you.
* Running a relay is great because it helps to make Tor users safer. Please make sure you're not undermining Tor or Tor user safety in your other activities. For example, if your other hobby is developing DPI tools for Palantir, or making people fear or hate privacy tools, please do not also run a Tor relay.
* Read our social contract and the other community documents: https://gitweb.torproject.org/community/policies.git/tree/
If there is a question about whether you or your relay are following the expectations laid out here, these are the documents we will be using to guide our choices.GusGushttps://gitlab.torproject.org/tpo/web/community/-/issues/267[Relay] Warn about the risk of ending up on blocklists2023-01-18T18:32:39ZGus[Relay] Warn about the risk of ending up on blocklistsSome relay operators running non-exits on their residential connections are having a bad time with blocklists. [This isn't a new thing](https://twitter.com/FiloSottile/status/1257714275763851264). In the tor-relays mailing list and the T...Some relay operators running non-exits on their residential connections are having a bad time with blocklists. [This isn't a new thing](https://twitter.com/FiloSottile/status/1257714275763851264). In the tor-relays mailing list and the Tor Forum, we've been asking relay operators to avoid running public nodes on their residential connections, for example, running a Snowflake proxy or a bridge will avoid your IP ending up on blocklists.https://gitlab.torproject.org/tpo/core/tor/-/issues/21989Should we tell Exits to reject all traffic if DNS fails?2023-02-07T10:19:20ZteorShould we tell Exits to reject all traffic if DNS fails?Tor Exits with broken DNS still allow Exit traffic.
But this slows down initial connections for clients, because the Exit will refuse all DNS requests. (Clients no longer cache DNS.)
Perhaps we should make Exits refuse traffic until th...Tor Exits with broken DNS still allow Exit traffic.
But this slows down initial connections for clients, because the Exit will refuse all DNS requests. (Clients no longer cache DNS.)
Perhaps we should make Exits refuse traffic until their DNS is working?
(Unless a non-default option is set?)
This would also fix legacy/trac#21900, where a broken DNS config really does stop all Exit traffic.https://gitlab.torproject.org/tpo/core/tor/-/issues/40689dirauth: Add new Faravahar 2.0 back to code2023-04-12T15:17:56ZDavid Gouletdgoulet@torproject.orgdirauth: Add new Faravahar 2.0 back to codeWe'll be in the next release removing the current Faravahar (https://gitlab.torproject.org/tpo/core/tor/-/issues/40688) due to its network location at team Cymru. Sina, its operator, is in the process of moving it out and securing a new ...We'll be in the next release removing the current Faravahar (https://gitlab.torproject.org/tpo/core/tor/-/issues/40688) due to its network location at team Cymru. Sina, its operator, is in the process of moving it out and securing a new location.
At this point, we'll add it back into the code with fresh new keys and IP. This ticket tracks this effort.https://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/19162Make it even harder to become HSDir2023-03-13T09:57:24ZGeorge KadianakisMake it even harder to become HSDirIn legacy/trac#8243 we started requiring `Stable` flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been...In legacy/trac#8243 we started requiring `Stable` flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been around for long get the flag. After prop224 gets deployed, there will be less incentive for adversaries to become HSDirs since they won't be able to harvest onion addresses.
Until then, our current plan is to increase the bandwidth and uptime required to become an HSDir to something almost unreasonable. For example requiring an uptime of over 6 months, or maybe requiring that the relay is in the top 1/4th of uptimes on the network.Tor: unspecifiedRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/72Some bridges don't have a valid status page2024-03-06T16:41:13ZCecylia BocovichSome bridges don't have a valid status page@gk found a bridge that doesn't have a valid status page, but it does show up in the extra info files that rdsys is using.
Relay search page: https://metrics.torproject.org/rs.html#details/47D7B70C2E411A941348AF2132D41BC4554FDD25
bridg...@gk found a bridge that doesn't have a valid status page, but it does show up in the extra info files that rdsys is using.
Relay search page: https://metrics.torproject.org/rs.html#details/47D7B70C2E411A941348AF2132D41BC4554FDD25
bridgestrap status page: https://bridges.torproject.org/status?id=47D7B70C2E411A941348AF2132D41BC4554FDD25
I've verified the bridge is in the extrainfo file. So rdsys seems to be throwing it out for some reason? If the bridge doesn't work, it should show up as dysfunctional but still be saved as a valid resource.meskiomeskio@torproject.orgmeskiomeskio@torproject.org2024-07-31https://gitlab.torproject.org/tpo/core/tor/-/issues/40424Relay ORPort is not reachable in Tor 0.4.5 (worked in Tor 0.4.4)2023-05-12T18:28:14Znod3Relay ORPort is not reachable in Tor 0.4.5 (worked in Tor 0.4.4)### Summary
After upgrading to Tor 0.4.5.9 the ORPort never becomes reachable
### Steps to reproduce:
1. Step 1
Start tor in a docker instance
2.
### What is the current bug behavior?
ORPort is never reachable
### What is the exp...### Summary
After upgrading to Tor 0.4.5.9 the ORPort never becomes reachable
### Steps to reproduce:
1. Step 1
Start tor in a docker instance
2.
### What is the current bug behavior?
ORPort is never reachable
### What is the expected behavior?
ORPort should become reachable
### Environment
Tor 0.4.5.9
Docker swarm 20.10.2
Alpine linux
### Relevant logs and/or screenshots
Dockerfile
```
FROM alpine
RUN apk add tor sudo
ADD torrc /var/lib/tor/
ENTRYPOINT ["/usr/bin/sudo", "-u", "tor", "/usr/bin/tor", "-f", "/var/lib/tor/torrc", "--MaxMemInQueues", "1024MB"]
```
torrc
```
DataDirectory /var/lib/tor
ORPort 9901
DirPort 9930
SocksPort 0
ControlSocket /var/lib/tor/tor.socket
ExitPolicy reject *:*
ExitPolicy reject6 *:*
ExitRelay 0
IPv6Exit 0
RelayBandwidthRate 10240 KBytes
RelayBandwidthBurst 15360 KBytes
Nickname nod3
ContactInfo email@localhost
```
Log output
```
Jun 30 16:40:12.383 [notice] Tor 0.4.5.9 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.9 and Unknown N/A as libc.
Jun 30 16:40:12.383 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 30 16:40:12.385 [notice] Read configuration file "/var/lib/tor/torrc".
Jun 30 16:40:12.393 [notice] Opening Control listener on /var/lib/tor/tor.socket
Jun 30 16:40:12.441 [notice] Opened Control listener connection (ready) on /var/lib/tor/tor.socket
Jun 30 16:40:12.441 [notice] Opening OR listener on 0.0.0.0:9901
Jun 30 16:40:12.441 [notice] Opened OR listener connection (ready) on 0.0.0.0:9901
Jun 30 16:40:12.441 [notice] Opening OR listener on [::]:9901
Jun 30 16:40:12.441 [notice] Opened OR listener connection (ready) on [::]:9901
Jun 30 16:40:12.441 [notice] Opening Directory listener on 0.0.0.0:9930
Jun 30 16:40:12.442 [notice] Opened Directory listener connection (ready) on 0.0.0.0:9930
Jun 30 16:40:14.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jun 30 16:40:14.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jun 30 16:40:15.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Jun 30 16:40:15.000 [notice] Your Tor server's identity key fingerprint is 'nod3 447EFB012D16720324301796D008D50E883A4378'
Jun 30 16:40:15.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'nod3 ESBUqZdtc4oGo3Pfim+Fv+v1Jf8hKpV22Shf0vtktAQ'
Jun 30 16:40:15.000 [notice] Bootstrapped 0% (starting): Starting
Jun 30 16:40:46.000 [notice] Starting with guard context "default"
Jun 30 16:40:47.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Jun 30 16:40:47.000 [notice] Unable to find IPv6 address for ORPort 9901. You might want to specify IPv4Only to it or set an explicit address or set Address.
Jun 30 16:40:47.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Jun 30 16:40:47.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Jun 30 16:40:47.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Jun 30 16:40:47.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Jun 30 16:40:47.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Jun 30 16:40:47.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Jun 30 16:40:47.000 [notice] Bootstrapped 100% (done): Done
Jun 30 16:40:47.000 [notice] Now checking whether IPv4 ORPort xxx.xxx.xxx.xxx:9901 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Jun 30 16:40:47.000 [notice] Now checking whether IPv4 DirPort xxx.xxx.xxx.xxx:9930 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Jun 30 16:40:48.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Jun 30 17:00:49.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at xxx.xxx.xxx.xxx:9901. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
[tord-log.zip](/uploads/d27b156ed6503a15a53a470a9988e586/tord-log.zip)
### Possible fixesTor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40203Detect misbehaving OpenDNS resolvers2023-02-07T10:19:12ZAlexander Færøyahf@torproject.orgDetect misbehaving OpenDNS resolversThe network health team is doing a lot of different scanning recently, and they have found a few exit nodes using the OpenDNS resolver to look up DNS requests for Tor clients.
OpenDNS is known for doing various naughty things to DNS res...The network health team is doing a lot of different scanning recently, and they have found a few exit nodes using the OpenDNS resolver to look up DNS requests for Tor clients.
OpenDNS is known for doing various naughty things to DNS responses, such as sending people to their advertisement pages and what not.
Tor already have a subsystem for detecting some of this (NX domain hi-jacking) and to see whether some known DNS lookups doesn't resolve properly (google, yahoo, and a few others).
@arma mentioned the following way of detecting this on IRC:
```
241120 22:45:14 + armadev: ADDRMAP b187399e2708155968a8375b83042767f69f21f0: share.riseup.net = 198.252.153.229
241120 22:45:14 + armadev: ADDRMAP dadcad37de5e22e7e1f323927260155eab3689c2: share.riseup.net = 146.112.61.108
241120 22:45:14 + armadev: ADDRMAP 2f64ea527c4aa6f99e261318dd1ff127828e2525: share.riseup.net = 198.252.153.229
241120 22:45:30 + armadev: $ host 146.112.61.108
241120 22:45:30 + armadev: 108.61.112.146.in-addr.arpa domain name pointer hit-phish.opendns.com.
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40661Do phase 3 of proposal 2892024-01-30T16:07:48ZGeorg KoppenDo phase 3 of proposal 289In [prop#289](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/289-authenticated-sendmes.txt) we included a deployment timeline. Currently we are at Phase 2 and Phase 3 contains the following:
```
This phase ...In [prop#289](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/289-authenticated-sendmes.txt) we included a deployment timeline. Currently we are at Phase 2 and Phase 3 contains the following:
```
This phase will effectively exit() all tor not supporting
"FlowCtrl=1". The earliest date we can do that is when all versions
not supporting v1 are EOL.
According to our release schedule[4], this can happen when our latest
LTS (0.3.5) goes EOL that is on Feb 1st, 2022.
```
We are past Feb 1st, 2022 and 0.3.5.x is gone for good for a while. Let's get to Phase 3 for the next major release at least then.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/web/community/-/issues/165Make clear that being a relay operator requires transparency about the relay ...2023-06-15T15:23:46ZRoger DingledineMake clear that being a relay operator requires transparency about the relay operator, not secrecyAs part of our work on the bad-relays team and the network health team, we periodically encounter relay operators who seem to think they should be keeping which relay they run secret from us and the world.
We should change the relay ope...As part of our work on the bad-relays team and the network health team, we periodically encounter relay operators who seem to think they should be keeping which relay they run secret from us and the world.
We should change the relay operator docs on community.tpo to make it clear that while Tor is about protecting users, being a relay operator is an act of transparency -- so people who want to run relays while themselves staying anonymous and secretive are not how we achieve a robust network.
I haven't looked yet to figure out where exactly in the docs we should do this change, or figured out what exactly we should change it to say. Bonus points if somebody jumps in and does these steps. :)GusGushttps://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/40614Report CPU overload2023-02-07T10:20:22ZAlex XuReport CPU overloadIn http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-03-08-16.59.log.html, it was agreed to drop CPU overload reporting in part on the basis that:
```
17:12:38 <asn> i have no idea how to measure CPU utilization in a multi-pla...In http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-03-08-16.59.log.html, it was agreed to drop CPU overload reporting in part on the basis that:
```
17:12:38 <asn> i have no idea how to measure CPU utilization in a multi-platform way
```
While it's true that there's no cross-platform way to measure CPU utilization, we don't actually want to know the percentage of CPU utilization anyways. Even if we did, it wouldn't be useful: suppose there are 2 CPUs, each at 50% utilization. Is tor overloaded? There's no way to tell using this information: maybe tor is using 50% of one CPU and something else is using 50% of another, so tor is not overloaded; or, maybe tor is pegging one CPU and is being bounced back and forth, so tor is actually overloaded.
What we really want to know is whether tor is bottlenecked by the CPU instead of by the network interface or by other nodes. What this means in the main loop is that normally, when tor goes to check for events, tor would like to block in poll or equivalent for a little while, not constantly be processing event callbacks. If poll always returns immediately, that means that lots of events are queueing up that tor isn't processing expeditiously; in other words, either the CPU is too busy or tor is swapping excessively.
The main problems with implementing this are:
1. how do we actually determine if poll returned "immediately"? a hardcoded duration will incorrectly classify very fast relays (with low duration between FD activation) as overloaded or incorrectly classify very slow relays (with high syscall overhead) as not overloaded or both. In the raw API, I think the best way to do this is to call poll with a timeout of 0, and see if any FDs become active. In libevent, I think the least worst way to do this is to occasionally call event_base_loop with EVLOOP_NONBLOCK, then use a prepare watcher to call event_base_get_num_events with EVENT_BASE_COUNT_ACTIVE. if it is non-zero, record potential overload and continue calling event_base_loop with EVLOOP_NONBLOCK; if it is zero, call event_base_loop without EVLOOP_NONBLOCK. Alternatively, it might be possible to just use the prepare watcher without EVLOOP_NONBLOCK, and check that the number of activated events is "small".
2. how many times does "excessive events" need to happen in order to be considered overloaded? 1? 10? 100? should it be time-based, e.g. we called event_base_loop with EVLOOP_NONBLOCK continuously for 60 seconds and it kept invoking callbacks?https://gitlab.torproject.org/tpo/core/tor/-/issues/40837zimmer family hitting max descriptor size2023-09-11T10:56:50ZRoger Dingledinezimmer family hitting max descriptor sizezimmer, one of our prolific relay operators, has recently started getting these complaints on his relays:
```
http status 400 ("Router descriptor was too large.") response from dirserver 204.13.164.118:80. Please correct
```
We talked t...zimmer, one of our prolific relay operators, has recently started getting these complaints on his relays:
```
http status 400 ("Router descriptor was too large.") response from dirserver 204.13.164.118:80. Please correct
```
We talked to him and it isn't a 'huge exit policy' issue, it is a 'huge family' issue.
In the glorious future, we will have implemented proposal 321 and we won't have this size explosion from family entries. But we don't live in that future yet, so we need some workaround in the short term.https://gitlab.torproject.org/tpo/core/tor/-/issues/40901Document for the Relay Operator community how to debug relays that are slower...2023-12-19T07:53:56ZAlexander Færøyahf@torproject.orgDocument for the Relay Operator community how to debug relays that are slower than what the operator expectsThis idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more...This idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more|less) memory/crashes (more|less) often/etc. many of these items are hard to give a definitive "yes, the cause of this is X" and it's very time consuming for the Network Team to debug each item individually with the operator.
It would be very useful to have a document in place that informs relay operators about the different situations that may impact performance and how they can get some performance measurements they can then compare to and see if our performance have truly regressed. This can also be used to push MetricsPort to more operators.
We can expand upon the document over time as we discover new ways to do this analysis and/or from feedback from the relay operator community.
This is related to:
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021409.html
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021407.html
This may be relevant to Arti Relay too.
CC @mikeperry for awareness.