Filename: 369-tls-sni.md
Title: Deterministic TLS SNI for Channel Certificates
Author: Clara Engler
Created: 5-Feb-2026
Status: Open
Ticket: #390

Motivation

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):

# 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 193.23.244.244 -connect 193.23.244.244:443 </dev/null

[...]
subject=CN=www.n5pgh5vsyltf.net
issuer=CN=www.ug3g5twr.com
[...]

These values are random, although this is just an implementation detail, with the specification not actually mandating any behavior there, as 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.

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 not 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.

Tor design proposals