- tor-dev - lists.torproject.org

Technical inquiry about tor-ptmgr of Arti
by pryty 05 Jul '26

05 Jul '26

Dear list, I'm writing a technical inquiry about tor-ptmgr. Although the issue #666 ( https://gitlab.torproject.org/tpo/core/arti/-/work_items/666 ) said that: " Some people would like to use pluggable transports in a context other than inside a Tor process for making Channels. Right now, ptmgr contemplates this but does not actually provide an API for it.", I saw that: ```rust #[tokio::main] asyncfnmain() ->Result<()> { tracing_subscriber::fmt::init(); letcommon_params=PtCommonParameters::builder() .state_location("/tmp/arti-pt".into()) .build() .unwrap(); letclient_params=PtClientParameters::builder() .transports(vec!["obfs4".parse().unwrap()]) .build() .unwrap(); letmutpt= PluggableClientTransport::new("./obfs4proxy".into(), vec![], common_params, client_params); pt.launch(PreferredRuntime::current()?).await?; loop { info!("message: {:?}", pt.next_message().await?); } } ``` at .crates\tor-ptmgr\examples\run-pt.rs which seems like it should actually work without tor. Does this example already intended a public API for using pluggable transports independently of Tor? If yes, why this issue is still open. I'd appreciate any clarification. Thank you. pryty26 pryty017(a)proton.me Sent with [Proton Mail](https://proton.me/mail/home) secure email.

1 0

[Proposal for Arti] Add REALITY as an optional pluggable transport for Arti
by pryty 01 Jul '26

01 Jul '26

Hi, dear developers and tor-dev I have been following the development of Arti closely and would like to suggest a new and modern feature: Adding support for the REALITY protocol as a optional new PT protocol in Arti. I suggest REALITY as a new optional protocol, since REALITY unlike traditional PTs which rely on traffic obfuscation or domain fronting, REALITY borrows real TLS sessions from existing websites, which could be very useful for Tor users, who needs to bypass DPI. Additionally, I would be willing to work on this new feature, if it's acceptable to you. However, in my opinion, it could be implemented as an new PT plugin via tor-ptmgr, with corresponding configuration changes in arti-client. I look forward to your feedback. Best regards,pryty26 --- Sent with [Proton Mail](https://proton.me/mail/home) secure email. (pryty017(a)proton.me)

2 1

Re: Selene: Tor-based p2p chat with RSA-8192 + AES-256
by Dharma Mati 18 Jun '26

18 Jun '26

Dear list, Paul suggested I share my reply to his question with the list. Here it is. Hello Paul, Thank you for reaching out — and thank you for your work on onion routing. I genuinely mean that. Without what you and your colleagues built, Selene wouldn't exist. You asked what makes Selene different from the other messaging tools that use onion addresses. I think there are a few things that make it stand out. It has native OBFS4 and WebTunnel bridge support with a built-in manager, so if Tor is blocked, Selene can still connect without requiring the user to configure system-wide bridges. You can also modify the listening ports so it doesn't conflict with other Tor instances running on the same machine. And you can request a new Tor circuit or generate a new onion address(http/chat), which gives users control over their privacy and connectivity. On top of Tor's transport, Selene adds its own application-layer encryption — RSA for messages and AES-256 for files. So even if someone were to compromise the Tor hidden service connection, the data itself remains encrypted with Selene's own keys. Furthermore @techmetx11 suggested on the list that I should consider moving to X25519 for key exchange instead of RSA. I'm genuinely open to that and will likely explore adding it as an option alongside RSA. Selene gives you two ways to connect. You can share .contact files with people you already know for private, contact-based chat. Or you can connect anonymously by sharing an onion address directly, without exchanging contact details — which is useful for ephemeral or one-off conversations where you don't want to establish a persistent contact relationship. I appreciate you taking the time to ask. With respect, Alamahant

1 0

Selene: Tor-based p2p chat with RSA-8192 + AES-256 (not a browser)
by Dharma Mati 18 Jun '26

18 Jun '26

Hello tor-dev,I'm the developer of Selene — a Tor-based peer-to-peer chat and file sharing application.What Selene is:- A chat app where each instance generates its own onion address- Peers share addresses with each other directly (no public discovery)- Files are shared as HTTP servers between confirmed contacts only- Built-in OBFS4 and WebTunnel bridge supportWhat Selene is NOT:- A Tor browser. You cannot browse .onion sites.- A gateway to the darknet. There is no public discovery of anything.- A general-purpose anonymity tool. It's just for private chat between people who already know each other.Encryption — and this matters:On top of Tor's end-to-end anonymity (everything stays inside the Tor network, never leaving it), Selene adds its own application-layer encryption:- Messages: RSA encryption (user-configurable up to 8192 bits)- Files: AES-256 encryptionSo even if someone were to compromise the Tor hidden service connection, the data itself remains encrypted with Selene's own keys. Defense in depth.Why I built it:I needed a p2p chat app that doesn't require opening ports on routers or corporate firewalls. Privacy and encryption came after solving that core need.Current availability:- Flathub: https://flathub.org/en/apps/io.github.alamahant.Selene- Arch Linux AUR: https://aur.archlinux.org/packages/selene-p2p- Gentoo overlay: https://github.com/alamahant/alamahant-overlay/tree/master/net-p2p/selene- GitHub: https://github.com/alamahant/SeleneWhat I'm asking:I'm not requesting formal endorsement. I would simply appreciate it if someone on the team could take a look. If you find it useful, consideration for inclusion in the Tor Browser User Manual or community resources would mean a lot.I'm posting here at Gus's suggestion after reaching out to frontdesk.Thank you for Tor — I couldn't have built this without it.With respect,Alamahant

3 2

Re: Using hidden service key with TLS client authentication
by Paul Syverson 16 Jun '26

16 Jun '26

Hi techmetx11, (Attempted resend since send from my Navy mail appearently failed to reach tor-dev. Apologies if you got this twice. -PFS) I don't know if this fits what you need. But we have used the onion address as subdomain to put it into TLS certificates in the case where there is an associated domain name. E.g. Mullvad has a TLS certificate with the following SANs o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.mullvad.net o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.www.mullvad.n… We've used this in a couple of ways, for self-authenticating traditional addresses and for sauteed onions. See e.g. https://arxiv.org/abs/2110.03168 and https://www.sauteed-onions.org/ Happy to talk more if asked about recent work on associating onion addresses with atproto handles as alternative/additional meaningful address. In case it helps for your use case, note that you don't need to keep the service accessible at the registered domain address. It only has to be available during issuance (depending on the means of verification used). You can also just get a certificate for an onion address. Issuance via ACME is still not available last I checked despite the efforts of Q Misell and others. Last I checked (some time ago) you can get a DV cert issued manually from HARICA or an EV cert from DigiCert. The syverSAN technique OTOH works fine with Let's Encrypt issuance. Hope that helps. Si sanus es, sanus sum, Paul > > On 6/8/26, 4:32 AM, "techmetx11 via tor-dev" wrote: > > > Hi tor-dev mailing list, > > > Is there a way to capsulate a Tor hidden service Ed25519 private key > inside a TLS EE certificate and use it in TLS? > > > I wanted to use this specifically for XMPP's server-to-server TLS > connections, which uses mTLS to prove if the client connecting is who > they say they are. Currently with XMPP Tor server-to-server connections, > we have to use dialback (telling the server to connect back to the > client to authenticate its identity, > https://xmpp.org/extensions/xep-0220.html <https://xmpp.org/extensions/xep-0220.html>) to prove it, which is a > legacy and insecure form of server-to-server authentication > > > If this is possible, then it would get rid of a reason to keep dialback > around and less roundtrip for the server authentication. > > > Kind regards, > > > techmetx11 > > > _______________________________________________ > tor-dev mailing list -- tor-dev(a)lists.torproject.org <mailto:tor-dev@lists.torproject.org> > To unsubscribe send an email to tor-dev-leave(a)lists.torproject.org <mailto:tor-dev-leave@lists.torproject.org> > > >

2 4

Using hidden service key with TLS client authentication
by techmetx11 10 Jun '26

10 Jun '26

Hi tor-dev mailing list, Is there a way to capsulate a Tor hidden service Ed25519 private key inside a TLS EE certificate and use it in TLS? I wanted to use this specifically for XMPP's server-to-server TLS connections, which uses mTLS to prove if the client connecting is who they say they are. Currently with XMPP Tor server-to-server connections, we have to use dialback (telling the server to connect back to the client to authenticate its identity, https://xmpp.org/extensions/xep-0220.html) to prove it, which is a legacy and insecure form of server-to-server authentication If this is possible, then it would get rid of a reason to keep dialback around and less roundtrip for the server authentication. Kind regards, techmetx11

2 2

Proposal: Tor Garlic Routing for .onion Services
by Kester Pembroke 08 Apr '26

08 Apr '26

Hello Tor Developers, I’d like to share a draft proposal for enhancing the privacy of Tor hidden services (.onion) through garlic-style routing. This idea is inspired by I2P’s garlic routing model and focuses exclusively on .onion services to avoid exit node issues and reduce network impact. Proposal Overview - Garlic bundles: Multiple encrypted messages (“cloves”) per bundle, including real requests, dummy traffic, and optional instructions. - Traffic obfuscation: Mandatory cover traffic, randomized timing, and optional asymmetric send/receive circuits to reduce timing correlation. - Goals: - Increase resistance to traffic correlation attacks - Reduce website fingerprinting risk - Enhance end-to-end privacy for hidden services Key Features - Compatible with existing Tor hidden service architecture - Optional multipath routing for further anonymity - Backward-compatible: Clients and services without garlic routing continue using standard cells I have attached a draft TIP-style document with full technical details, security analysis, and proposed implementation steps. I would greatly appreciate any feedback, comments, or suggestions from the Tor developer community. Thank you for your time and consideration. Best regards, Kester Pembroke

2 1

Work to get tor on Sailfish OS
by Niel Nielsen 10 Mar '26

10 Mar '26

Hello all, Thought you would find it interessting on how I made some work to create tor on Sailfiosh OS for Jolla phones. This is a continuation of my (personal) work, when I had a tor exit node running on a Jolla phone, for about a year, until that device died. What I did. Made a port of tor, for Sailfish OS Made a QML application, which enables a user to easily start/stop tor service Also, created an RPM that will help the user install and activate a tor exit node with a hidden service https://sec1.dk/blog/tor-sailfish-blog.html Best Regards Niel

2 2

Proposal: Deterministic TLS SNI for Channel Certificates
by Clara Engler 09 Feb '26

09 Feb '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.

4 6

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