Proposal: Deterministic TLS SNI for Channel Certificates
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.
Dropping a few more words with regard to alternatives: ``` # Alternatives ## Prefix-based SNI with entropy Potentially, one could also introduce additional entropy by letting clients send a SNI of the format `<FINGERPRINT><RANDOM>.home.arpa`, with `<RANDOM>` being a random length suffix of hexadecimal characters. The advantage this offers is to introduce slightly more obfuscation by making it harder to detect the likelihood of Tor traffic by the based on the TLS handshake alone, though it will of course not protect against and a person really interested in whether you are using Tor or not. Besides, it requires the reverse proxy to support regex/prefix based SNI matching, which certain reverse proxies may not support, for a good reason. ## Traditional NAT One may also configure the IPv4 frontend server to simply not do any Tor TLS forwarding based on the SNI and just designate a dedicated port from which traditional NAT/PAT with some IPv4/IPv6 glue will be performed. Advantages of this include, that it does need any change in the current implementation. Disadvantages include, that it would require larger complexity for the frontend server, which is usually designed to be low-complexity. On Linux for example, it would involve enabling routing logic through various sysctl's. Not only does this increase the attack surface because more complex kernel code is loaded during runtime, but it also greatly increases the complexity of firewall rules, as NAT is more advanced than traditional input/output based allow/blocklists. ```
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.
Do server providers even allow you to use a domain that you don't own (such as the proposed *.home.arpa)? That sounds like it could lead to issues for them down the line, e.g. if a customer comes along who owns a domain I "squatted" for my server. Thus, even if this is permitted nowadays, I wouldn't be surprised if they start locking this down.
* 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.
Why would they even bother with checking the fingerprints? Surely the odds of a "legitimate" service using [0-9a-f]{30}.home.arpa are negligible.
[this] will do nothing for an attacker who is actively trying to detect and/or block the use of Tor.
The simpler it is to block vanilla Tor, the harder it will be for censors to fuck it up. For one, you would no longer need to keep an up-to-date consensus - and some people do seem to exploit the fact that censors don't always keep it updated[1]. [1] https://github.com/ValdikSS/tor-relay-scanner Back to my first point, maybe relays should be able to set an arbitrary SNI instead? This would be much more flexible for e.g. when your provider requires you to actually own the used domain, but it also would mean that most relays could keep using the randomly generated domains. I assume this would only be used by a minority of relays, and the SNI would only be embedded in the microdescriptor if actually required, so hopefully this shouldn't affect their sizes too much?
On Mon, Jan 26, 2026 at 06:37:41PM +0100, dzwdz via tor-dev wrote:
Do server providers even allow you to use a domain that you don't own (such as the proposed *.home.arpa)? That sounds like it could lead to issues for them down the line, e.g. if a customer comes along who owns a domain I "squatted" for my server. Thus, even if this is permitted nowadays, I wouldn't be surprised if they start locking this down.
Tor TLS certificates are self-signed, the names in there can be anything. Ranging from a random string ending with ".com" to even things such as google.com. The point is, that the trust for authenticity in Tor itself is established outside of TLS certificates with various in-protocol mechanisms. With regard to home.arpa: This domain is specifically reserved in RFC8375. It can be used by anyone without permission. Even outside of this proposal, I think that this is way better than generating a random string and appending .com to it, like what we are doing at the current moment, and what you are asking if this is even allowed in the first place; to which the answer is a clear yes, as this is the status quo.
Back to my first point, maybe relays should be able to set an arbitrary SNI instead? This would be much more flexible for e.g. when your provider requires you to actually own the used domain, but it also would mean that most relays could keep using the randomly generated domains.
But how would you communicate that domain to clients? The SNI must be known to clients for use in their `ClientHello`, similar to a host in a `Host` HTTP header. AFAIK, IP addresses may not be used as FQDNs in SNIs. Thank You Clara
On 26/01/2026 11.59, Clara Engler via tor-dev wrote:
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`.
Once we are migrated to Arti on the network side, I don't think it would be unreasonable to begin thinking about a Tor network where we manage the keys ourselves, but where the Arti Relay daemon can request a valid certificate via the ACME protocol from a provider such as Let's Encrypt. For censorship reasons, we should, of course, always fall back to self-signed certificates and not rely on the WebPKI for TLS trust validation in the case where the ACME certificate request fails and no certificate is issued. Cheers, Alex -- Alexander Hansen Færøy
On Mon, Jan 26, 2026 at 11:59:05AM +0100, Clara Engler via tor-dev wrote:
below is a proposal I have been working on.
Opened an upstream merge request: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/461 Thank You Clara
Clara Engler:
# Alternatives
## Traditional NAT
One may also configure the IPv4 frontend server to simply not do any Tor TLS forwarding based on the SNI and just designate a dedicated port from which traditional NAT/PAT with some IPv4/IPv6 glue will be performed.
If a specific port can be reserved, and you want to avoid NAT, you can configure nginx so that it forwards every connection to that port to the right IPv6 address, I guess. Wouldn't this solve all of your concerns? -- boyska
participants (4)
-
Alexander Hansen Færøy -
boyska＠riseup.net -
Clara Engler -
dzwdz