July 2026 - tor-relays - lists.torproject.org

Post-Quantum Cryptography in Tor's TLS Layer: Help needed!
by Alexander Hansen Færøy 06 Aug '26

06 Aug '26

Hello Tor Relay Operators, With the arrival of OpenSSL 3.5.0 in 2025, we finally had an important missing piece of infrastructure to start enabling the Tor network to support Post-Quantum Cryptography in the outermost cryptographic layer of the Tor protocol. Since Tor version 0.4.8.17, we have supported the x25519/ML-KEM-768 hybrid handshake in our TLS layer, and we have gradually seen more relays supporting it in the production network. Tor Browser has been built against OpenSSL >= 3.5.0 since (at least) version 13.5.22, released in September 2025, and therefore supports Post-Quantum TLS handshakes today, but it requires that its guard node supports it. We need to give a big shout-out to the OpenSSL Team here to get this out and available to the masses! <3 Since Q3 2025, I've been running some semi-regular scans of the Tor production network to check for TLS cipher suite availability. This work started as part of the first Tor Community Gathering back in October, 2025[1]. The results are as follows: In January, around 28% of the Tor relays supported the Post-Quantum TLS handshake. The scan I did yesterday showed an increase of around 4 percentage points to 32.32%. Out of 9476 scanned relays, 9185 were reachable, 291 were unreachable. Of the 9185 reachable relays, I saw the following distribution of cipher suites: `TLS13_AES_256_GCM_SHA384`: 9023 relays. `TLS13_CHACHA20_POLY1305_SHA256`: 158 relays. `TLS13_AES_128_GCM_SHA256`: 4 relays. For the key exchange groups, I saw the following distribution: `secp256r1`: 6212 relays. `X25519MLKEM768`: 2969 relays. `X25519`: 4 relays. Of the Directory Authorities, 5 of them supported the `X25519MLKEM768` key exchange group during the TLS handshakes. 2969 / 9185 * 100 = 32.32% of relays support the `X25519MLKEM768` cipher suite. This number is a good start, but we should ideally bump it up! You can see the individual results for your relay(s) in the big table available at https://ahf.me/tor-tls-pqc/2026-02-26/ -- entries without a cipher suite or key exchange group were unreachable at the time I ran the scan. These missing entries can be due to a network problem anywhere on the path between my host and yours, so don't get worried if your relay is missing :-) The scanner I used is free software and is available as part of the Network Health Team's Margot tool[2], used for various analysis purposes. Please note that the goal here isn't to enumerate all available cipher suites for each relay, but instead I'm interested in the "strongest" possible cipher suite my custom client can negotiate with each relay. My ask for you as the relay operator community here is as follows: Next time you folks are doing maintenance on your relay(s), please have a look at whether you can upgrade either your packages or underlying software distribution to a version such that you either get a new enough version of OpenSSL (>= 3.5.0), or if you are a LibreSSL user, check whether the LibreSSL project supports the ML-KEM hybrid handshake, and upgrade to that version. It looks like the LibreSSL project is currently working towards supporting the ML-KEM handshake in the next upcoming release[3]. For Debian users, to get a new enough OpenSSL version that supports the PQC TLS handshake, you need to upgrade to (at least) Debian Trixie. For everybody else, it's best to check your respective software distribution's package management system to find the version you need to upgrade to. For Arti users, a licensing issue with the currently available crypto providers in Arti prevented enabling the ML-KEM handshake. Nick, however, has recently been making progress on this matter and has a patch up that is now pending upstream review[4]! :-) If you are excited about exploring different aspects of the Tor ecosystem, talking with other Tor enthusiasts, and you have nothing planned for your weekend in two weeks, I highly encourage you to look into the next Tor Community Gathering in Denmark. The event takes place from 2026-03-13 to 2026-03-15. For more information, check out our website at https://onionize.space/2026/ Thank you all for all the work you do to make Tor better! <3 Cheers, Alex [1]: https://onionize.space/2025/ [2]: https://gitlab.torproject.org/tpo/network-health/margot/ [3]: https://github.com/libressl/portable/blob/a989b7acb9a475fde656e48dbcb38289d… [4]: https://github.com/RustCrypto/rustls-rustcrypto/pull/143 -- Alexander Hansen Færøy

4 8

Tor Relay Crash
by Lavender I Tor Relay 04 Aug '26

04 Aug '26

Hello, I've been tearing my hair out a bit lately. I launched a Tor middle relay a few weeks ago, but every so often, I get a dramatic spike in upload traffic, and the relay becomes almost unusable—or even crashes... I thought it might be a DDoS attack, but I'm not sure. Is something going on with the network right now, or is it on my end? I’ve set the relay’s bandwidth rate to 52 MB and 55 MB burst, but sometimes the upload speed hits 100 MB/s… The relay averages around 10 MB, and then suddenly it runs at 60–100 MB/s for several hours at a time. I already have a UFW firewall that only allows the relay ports on my server. It takes a while to get flags, and since my relay crashes because of these network spikes, I lose a good portion of my flags and basically have to start all over again... It's really frustrating. Thanks

3 4

Heads up: anti-censorship tools now packaged on deb.torproject.org
by Micah Anderson 01 Aug '26

01 Aug '26

Greetings, We're currently preparing 4 new Debian packages to be included in the Tor Project Debian repository hosted at "deb.torproject.org" in the coming days: * lyrebird * webtunnel * snowflake-proxy * snowflake-client If your system is configured with "deb.torproject.org" in your APT sources and any of the above packages are installed from the regular Debian archive, they will automatically upgrade the Tor Project-published versions. We're doing this to ensure that downstream users of these important anti-censorship tools have an update channel that allows them to receive timely upgrades automatically. That being said, packages from both channels should remain compatible and interchangeable. If you encounter any issues with them, please let us know by creating an issue in https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items. If you wish to add "deb.torproject.org" in your Debian system's APT sources, please follow the instructions at: https://support.torproject.org/little-t-tor/getting-started/installing/#deb… -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

2 1

reply to: 5 to 10 times more outgoing than incoming traffic
by code9n＠pm.me 01 Aug '26

01 Aug '26

Update: re. 5 to 10 times more outgoing than incoming traffic on relay : 6AD7A3E682FE74BDFE34AC0F0D17714480BA773B About an hour after the large difference between incoming and outgoing it had quietened down to about 7MB each way. By two hours after that it is up to around 20MB each way - so I guess it's sorting itself out. I'd be interested if anyone has any idea what happened, though. thanks, Pete

6 5

about vanguards
by Markus Reichelt 31 Jul '26

31 Jul '26

Hi, I do wonder if https://github.com/mikeperry-tor/vanguards is deprecated/dead/no longer needed. Already asked on IRC but got no reply. And then there is https://github.com/mikeperry-tor/vanguards/issues/99 Thanks for any pointers.

1 0

Circuit-building DoS wave: 20x peak, 8x sustained circuits on guard relays since Jun 25
by Tor at 1AEO 28 Jul '26

28 Jul '26

Summary: - Our guard relay family has been under a sustained circuit-building DoS wave since 2026-06-25 23:00 UTC, still ongoing: open circuits at 20x peak and 8x sustained, onionskin load 7x, stream creation 12x -- but bandwidth only +20%. Millions of near-idle circuits. See the attached charts (fleet open circuits, onionskin processing, and bandwidth, Jun 10 - Jul 10). - Every location and provider we run (EU + NA) was hit simultaneously with the same onset time, and the load arrives over existing OR connections (established TCP counts stayed flat). There is an onion-service introduction component. Looks network-wide or family-targeted, not host-specific. - Impact contained so far: tor's DoS defenses engaged, brief onionskin drops on a small subset of relays, consensus flags dipped ~5%, zero TCP port exhaustion and zero global rate-limit events. - EU servers shed 10-20% of real traffic, which are commonly closer to capacity, while NA absorbed more and have never been at capacity. - Jun 25 - Jul 10, full event window vs prior 15 days: open circuits +719% (the 8x sustained figure), onionskins processed +639%, stream creation +1126%, bandwidth +20% Details, chronological (times UTC; metrics from MetricsPort, fleet-wide): - Jun 22, 12:00-24:00 -- 12h precursor burst: open circuits ~8x normal, then two quiet days. - Jun 25, 23:00 -- onset: onionskin processing ~2.5x within 30 minutes; open circuits ~6x within 3 hours. - Jun 26-27 -- first major waves: introduce2_rejected bursts an order of magnitude above normal (peak Jun 27 03:00); conn_rejected ~5x baseline with bursts to ~10x. - Jun 26-28 -- overload symptoms: brief onionskin drops on a small subset of relays; tor's OOM handler ~10x more active; Stable/Fast/Running flag counts dip ~5% (Guard -3%). - Jul 5, 08:00 -- the 20x peak: open circuits hit ~20x baseline, the event's maximum so far. - Jul 6-10 -- slow decay: still ~5-6x baseline as of Jul 10. The symptom class matches the 2022-2023 network DDoS -- circuit creation floods overloading non-exit relays' onionskin processing, plus an onion-service introduction component: https://forum.torproject.org/t/tor-relays-dos-attacks-status-update/5333 https://blog.torproject.org/tor-network-ddos-attack/ Metrics to compare on your relays: tor_relay_circuits_total{state="opened"} tor_relay_load_onionskins_total tor_relay_streams_total tor_relay_dos_total (by type) Is anyone else seeing this since Jun 25? Happy to share more detail.

5 12

1gbp/s Tor Relay
by Lavender I Tor Relay 25 Jul '26

25 Jul '26

Hello, I was wondering if it's possible to allocate 1 Gbps of bandwidth to my Tor relay, or if it would be better to create multiple instances on the same server? I have a dedicated server in a data center. When I look at the list of the fastest relays, I see that some manage to reach 1 Gbps on a single instance, but I assume that requires a very powerful CPU and a very high single-core clock speed, given that my CPU is a bit old. Thanks!

4 5

Relay measured fine by moria1 but 0/26 measurements at maatuska (all stream errors)
by Beacon Tor Node 22 Jul '26

22 Jul '26

Hi all, I'm running an exit relay and seeing a strange discrepancy between bandwidth authorities. Some measure my relay without any problem, while others fail every single attempt with stream errors. Relay: beacon Fingerprint: 85082CD18CF6C931968105DFFFDDE82EBC4C9AF8 Observations from 2026-07-22: moria1 (13:47 UTC) — success=3/3, error_stream=0, error_circ=0, bw=6400 tor26 (06:23 UTC) — success=1/3, error_stream=0, error_circ=2, bw=1 maatuska (14:21 UTC) — success=0/26, error_stream=26, error_circ=0, unmeasured=1, vote=0 longclaw (09:32 UTC) — success=0/7, error_stream=7, error_circ=0, unmeasured=1, vote=0 gabelmoo — no data for this relay What stands out: error_circ is 0 at both maatuska and longclaw, so circuits build fine. The failures happen at the stream stage, and they happen every single time. Meanwhile moria1 measures the same relay flawlessly on the same day. Configuration: ExitRelay 1, ReducedExitPolicy 1, IPv6Exit 1, RelayBandwidthRate 37 MBytes, RelayBandwidthBurst 42 MBytes What I have checked locally, without finding anything: - DNS: local Unbound resolver, 0 serverfailed, 0 refused, 0 truncated, 213 timeouts out of 4920 queries (~4%) - IPv6: globally routable, verified from outside - MTU: full 1500 bytes pass unfragmented on both v4 and v6, no packet loss, ~6ms latency - TCP: ListenOverflows 0, ListenDrops 0, PruneCalled 0, conntrack 710/65536 - File descriptors: 65536 limit, ~620 active connections - OOM: tor_relay_load_oom_bytes_total 0 across all subsystems - Onionskins: 0 dropped - Firewall: outbound policy ACCEPT, nothing blocked - Tor logs: no warnings or errors over the past several days - System clock: synchronized via NTP The relay is relatively young (relay_in_recent_consensus_count between 28 and 85 depending on the authority), so I'm also open to the possibility that this simply resolves itself with more measurement attempts over time. Thanks, beacon

1 0

relayor v26.2.0 is released - Goodbye "MyFamily"
by nusenu 22 Jul '26

22 Jul '26

Hi, relayor v26.2.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v26.2.0 This release marks the end of "MyFamily" support in relayor. Since all supported tor versions support the Happy Family design there is no reason to continue supporting the old "MyFamily" method to declare relay families. relayor is an ansible role that helps you with automating tor relay operations https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes since v26.1.0: - remove MyFamily support: The last tor version that required MyFamily (0.4.8.x) in addition to Happy Family support reached end-of-life on 2026-06-01 - use absolute filter name to fix error "No filter named 'ipaddr'" kind regards, nusenu -- https://nusenu.github.io

7 9

If the IPv6 ORPort can't be reached, will clients/relays fall back to the IPv4 ORPort?
by forest-relay-contact＠cryptolab.net 21 Jul '26

21 Jul '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. If a client or relay with IPv6 attempts to connect to a relay's IPv6 ORPort and receives no response, will it fall back to IPv4 or will it consider the relay unreachable? Assume that the directory authorities are able to reach the v6 ORPort. Is the behavior different if there is an explicit error returned, e.g. RST or an ICMPv6 no route to host? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCal6ZDgAKCRAw+TRLM+X4 xgM7AP9xJhuSw8vYilYYbtzscuPLZk8BMY58gqPL2gocHYy/9wEAnduiOSjAeG6c 2yzboG7z5+HCV56tjIwXhuUTrprCmAY= =CQEB -----END PGP SIGNATURE-----

4 7