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.
_______________________________________________
tor-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
