- tor-dev - lists.torproject.org

Proposal: Deterministic TLS SNI for Channel Certificates
by Clara Engler 27 Jan '26

27 Jan '26

Hi tor-dev@, below is a proposal I have been working on. I am currently thinking about setting up a physical colocation with some of my friends for our servers and this problem came up when talked about hosting Tor relays with our planned setup. I have also heard that other colocations use a similar one, so I doubt we are the only ones encountering this issue. Feel free to reply with feedback and suggestions. Thank You Clara --- ``` Filename: XYZ-tls-sni.md Title: Deterministic TLS SNI for Channel Certificates Author: Clara Engler Created: 26-Jan-2026 Status: Open ``` # Introduction Tor uses self-signed TLS certificates for the underlying channel communication. These certificates themselves serve no deep purpose except for being necessary for TLS communication. The actual authentication of a channel happens inside the protocol through cells such as `CERTS`, `AUTH_CHALLENGE`, and `AUTHENTICATE`. The only in-protocol use of TLS certificates is the use of its SHA256 hash in the channel authentication. If one looks at the certificate of a relay, one finds the following values for the Server Indication (SNI): ```text # moria1 openssl s_client -showcerts -servername 128.31.0.39 -connect 128.31.0.39:9201 </dev/null [...] subject=CN=www.wazqogv7u.net issuer=CN=www.cdf5wqohuheupxt7l.com [...] # dannenberg openssl s_client -showcerts -servername 128.31.0.39 -connect 128.31.0.39:9201 </dev/null [...] subject=CN=www.n5pgh5vsyltf.net issuer=CN=www.ug3g5twr.com [...] ``` These values are apparently random and have no deep meaning, which is fine, given that Tor does not use TLS certificates for authenticity directly. Similarly, WireGuard/tcpdump reveals that a client also generates a random SNI in its `ClientHello` when opening a TLS connection. # Why random SNIs can be a problem In 2026, IPv6 adoption is still growing. One may operate a server in a colocation that has a dedicated IPv6 address but a shared IPv4 address. The shared IPv4 address itself is often an additional server running an nginx (or something similar) that inspects the SNI and forwards the TLS traffic (which does not terminate here) to the respective endpoint, in this case potentially a Tor relay. Right now, it is not possible to operate a relay in such a colocation setup, as matching Tor traffic based on TLS data is not possible. # Solving the issue In order to mitigate the issue, this proposal recommends changing the SNI in certificates from randomness to `<FINGERPRINT>.home.arpa`, with `<FINGERPRINT>` being the base16 lowercase fingerprint of the relay. Clients MUST use this format when sending their `ClientHello`. Relays MAY use this format in the X509 certificates they generate for use with TLS. # Anti-Censorship and Privacy Considerations The use of a 40 character fingerprint followed by the `.home.arpa` suffix makes it possible to detect the use of Tor on TLS level. However, I would argue that this is not necessarily a problem and does not places eavesdropper in a privileged position, because of the following constraints: * Use of Tor is already detectable by the destination IP and destination port number when initiating a TCP connection, which is a mandatory step in using Tor. * If a censor were to use fingerprints alone for detecting censorship, the censor would need to obtain a consensus which already contains the IP addresses plus port numbers anyway. * Given this fact, it is evident that this does not give the censor any practical advantage over blocking via TLS SNI versus IP/port, as both blocking mechanisms require the censor to obtain the same pieces of public information, namely a consensus document. A potential downside however might be, that this allows for easier detection of Tor traffic. For example, tools such as WireGuard, which usually do not come with a Tor consensus required for detecting Tor traffics, may flag traffic as Tor-traffic if the `ClientHello` contains a 40-character base16 hostname followed by .home.arpa`. It remains an open question on how critical this piece of information is. It might make life easier for script kiddies but will do nothing for an attacker who is actively trying to detect and/or block the use of Tor.

3 4

TorPP: Tor protocol implementation in C++23
by Larry Underwood 18 Jan '26

18 Jan '26

Hi devs, Please let me share with you TorPP: A header-only, zero-dependency Tor protocol implementation in modern C++23, created with Claude Opus 4.5. All code is 100% AI-generated and was created for fun and evaluation. It turned out surprisingly well — though I'd still recommend not using it to escape authoritarian regimes just yet. I invite you to check it out — first released with this mail: P.S. I won't have time to maintain TorPP, so if you like it — clone/adapt/adopt it please! Have a great day! AAAAC3NzaC1lZDI1NTE5AAAAIFV24QQBIfOq4TKl5cuqWDDh5UsWSj5m5StsoO5/Xr1w Sent from 🔒

1 0

What happens to my hidden service?
by Liste 29 Dec '25

29 Dec '25

Hidden service is unavailable, but tor is running. Tor's log: Dec 12 18:10:27.000 [notice] Your Guard SECxFreeBSD64 ($D7DB8E82604F806766FC3F80213CF719A0481D0B) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 199/285. Use counts are 101/101. 253 circuits completed, 0 were unusable, 54 collapsed, and 15 timed out. For reference, your timeout cutoff is 60 seconds. is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it could also mean an attack against you or potentially the guard itself. Dec 12 18:15:53.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service xxxxxxxxxxxxxxx. Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. [268 similar message(s) suppressed in last 600 seconds] Dec 11 13:43:12.000 [warn] onion_skin_client_handshake failed. Dec 11 13:43:12.000 [warn] circuit_finish_handshake failed. Dec 11 13:43:12.000 [warn] connection_edge_process_relay_cell (at origin) failed. Dec 11 00:34:57.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service .... Dec 10 10:09:01.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:03.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:04.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 12:42:19.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t.

3 2

Feedback System for the Tor Browser
by Bruno Melo 05 Dec '25

05 Dec '25

Hello Tor Developers, My name is Bruno, and I am currently doing my Thesis under the guidance of professor Kevun. My Thesis focuses on developing a system to enable users to submit anonymous reports on usability issues experienced while using the Tor Browser. To do so, I studied the state of the art in private data collection and analyses, and compared all the most relevant solutions between each other. This research led me to the POPSTAR protocol, a system that enables the submission of reports protected by k-anonymity. In this system, reports are constructed in a manner that the Server collecting them is unable to decrypt any single report individually. Instead, it must aggregate groups of similar reports. Each report contains a secret share of the symmetric key for the given group. When a group reaches threshold k, the server is able to combine the shares in order to recover the symmetric key, and therefore perform decryption of the group. The protocol does not require cooperation between clients. It only requires the clients to communicate with two non-colluding servers, a Randomness Server, which provides entropy to construct the report, and lastly the Aggregation Server, which collects the reports and attempts to decrypt them. We implemented this system in Rust, with the required Servers as Onion Services. Professor Kevun also provided me with a Browser Extension he has been working on as the interface for this system. In this email, I include the URL for the github repository, so that you can have a look, and run a demo. If you are interested, I can follow up this email with a document explaining the protocol in more detail. Here is the URL for the repository: github <https://github.com/Reidasfestas/AnonymousReportingForTor.git> Thank you very much for your time, and I hope to hear back from you.

1 0

Merging "Approved" Arti MRs
by Neel Chauhan 07 Nov '25

07 Nov '25

Hi, As you may or may not know, I have two Arti MRs which are approved but not merged: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3432 https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3439 Could those two MRs please be merged? I hope you have a great day/evening. Best, Neel Chauhan

1 0

New Contributor Interested in Tor Development and Network Security
by TUSHAR KANT 01 Nov '25

01 Nov '25

Hello everyone, I’m *Tushar Kant, a third year undergraduate student at Indian Institute of Technology Jodhpur, India* passionate about *cryptography, network security, and privacy-preserving technologies*. I’ve been deeply interested in understanding how the *Tor network* achieves anonymity through *onion routing* and its large-scale relay-to-relay architecture that forms the backbone of user privacy on the internet. My technical background includes a solid foundation in *cryptography, encryption/decryption, hashing*, and general *network security concepts*. I’m proficient in *C++* and *Python*, with experience in *backend development*, which I plan to leverage in contributing to Tor’s core or related components. I recently joined the Tor Forum, subscribed to the *tor-dev mailing list*, and am exploring the repositories to get familiar with the codebase and contribution workflow. While I aim to contribute consistently to Tor, I am also looking forward to potentially being part of *GSoC 2026* with The Tor Project if the opportunity aligns. I would greatly appreciate any guidance on where to begin or which areas of the project would be most suitable for someone with my skill set. Looking forward to collaborating and learning from this community. Best regards, *Tushar Kant*

1 0

Question about Advertised BW listed on metrics webpage
by am 19 Oct '25

19 Oct '25

Hey there, My VPS is dedicated to running a Tor relay server, so the performance should be good. However, your Relay Search page (metrics.torproject.org) now says the speed is only just "XXX KiB/s"! (X is a number) This should not be true. I ran the `speedtest --secure --server XYZ` on the server in question, and it returns: > Using server A Download: 98.34 Mbit/s Upload: 120.44 Mbit/s > Using server B Download: 88.81 Mbit/s Upload: 104.86 Mbit/s > Using server C Download: 94.34 Mbit/s Upload: 103.05 Mbit/s I also checked the firewall configuration, and it did not limit anything. Are you sure your network measurement server is not overloaded? How about teaming up with speedtest servers to measure real network value? So the questions are: Q1. Where are you measuring this from? Q2. If the Advertised BW is just this low, doesn't my Tor relay won't be used at all?

2 1

Proposal 365, review notes
by Ian Jackson 14 Oct '25

14 Oct '25

Hi. I read the proposal here https://spec.torproject.org/proposals/365-http-connect-ext.html I hate these notes: * Tenses are weird. The whole proposal is written in a weird mix of tenses and sometimes in a weird mood. Writing the specifications in the future tense is confusing and will make moving the text to the main spec (which we should do after approval and as part of implementation) much harder. There should not be statements like "we should". Specifications, even proposals, should be definitive and therefore should be definite. So everything should be written in the present imperative. * "X-Tor-RPC-Target: Arti RPC support" is weird. Firstly, is this being a protocol registry? Secondly, do we not have a notion of critical extensions? We should be using that for something like this. * Proxy-Authorization Don't we need to continue to support http clients where we can't specify custom headers? If so then this spec is a recipe for continuation of the bad protocol where we use the whole of the Proxy-Authorization contents as an unconditional input to isolation. * Optimistic data This has a framing hazard, which could be a vulnerability in some circumstances. I wrote about this in this torspec MR https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/419#note_32… AFAICT that means if that MR merges, this feature will be removed? That would resolve the concern. * "X-Tor-Family-Preference: IP version preferences" What is this for? Is there not an existing way to control this over HTTP? * "X-Tor-Proxy: Indication for Tor proxy protocol support" Why does this need to be separate from the X-Tor-Capabilities ? * Capabilities > Clients SHOULD NOT inspect the contents of this header to determine > whether a given feature is supported or not. Should be MUST NOT. Capability guessing via version strings is completely terrible. I suggest: Clients MAY use this to determine whether some software has a particular bug, but the matching MUST NOT treat any future versions as buggy. So the bug must be fixed before this technique can be used. (This is the rule adopted by the PuTTY team for compatibility with broken ssh servers.) Thanks for your attention, Ian.

2 2

Proposal 357, review notes
by Ian Jackson 24 Sep '25

24 Sep '25

Hi. I read the proposal here https://spec.torproject.org/proposals/357-circ-key-exporters.html I had these notes: * AFAICT "KH" is not defined anywhere. At least, there is no cross-reference for it. Perhaps that aspect of the spec should be tidied up first? Or is KH being introduced here? The proposal is unclear. If it is being introduced, it should be defined. * There should be a registry of customisation strings. (Probably one for the whole of torspec) Thanks, Ian.

2 1

Piloting a new contributor workflow on gitlab.torproject.org
by Micah Anderson 06 Aug '25

06 Aug '25

Hi all, If you've recently tried to fork a Tor repository into your personal gitlab.torproject.org namespace and received an error, you’re not alone. This is a known limitation of our current GitLab setup. To address this, we are piloting a new contributor workflow designed to make it easier for community contributors like you to propose changes, open merge requests, and collaborate, without needing write access to Tor’s canonical GitLab repositories. We’ve created a shared GitLab group for contributor forks called tor-contributors[0]. This group hosts mirrored forks of selected Tor projects. When you want to contribute, you can request access to the relevant contributor fork, create a branch (e.g., username/fix-x), and open a merge request back to the canonical repository. We’re looking for contributors who are actively working on changes and would like to participate in this pilot by trying out the workflow and providing feedback. If that’s you, please follow the onboarding instructions[1]. To help keep things manageable, we ask that people only request access if they are preparing to open a merge request. If you're just curious or want to follow along, there is no need to request access, we will continue to share updates as the pilot evolves. Thanks, and we look forward to your feedback. Thanks, Micah 0. https://gitlab.torproject.org/tor-contributors/ 1. https://gitlab.torproject.org/tor-contributors/meta -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

1 0