tor-dev

tor-dev@lists.torproject.org

February 2026

2 participants
1 discussions

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