What is REALITY?

A conventional TLS-wrapped tunnel needs a domain and a certificate. That requirement creates a chain of small signals, none fatal alone, which together make the endpoint identifiable.

• The domain is registered, and registration is a public record with a date, a registrar and often a pattern shared with other domains created for the same purpose.
• Publicly trusted certificates are published to Certificate Transparency logs, which are searchable by anyone. A domain's certificate history is not private.
• The domain has to resolve to the endpoint address, so the two are permanently linked in DNS.
• The hostname is stated in the clear in the handshake, so it can be matched against a list.
• Most decisively: if a system connects to the endpoint itself without valid credentials, a naive server behaves in a way no ordinary web server would.

Each of these can be mitigated — use an aged domain, use a certificate authority with less scrutiny, keep the domain out of public lists. None of them can be eliminated, because a server that holds its own certificate for its own domain is, by definition, a distinct thing that can be found.

REALITY inverts the problem. Instead of obtaining a certificate that must then be made to look innocuous, it borrows the identity of a genuine, unrelated, popular website — and when anyone without valid credentials connects, it gives them that genuine website.

1. 1

   The client announces a real site

   It opens a TLS handshake naming a legitimate high-traffic domain that the operator has chosen. To an observer, this is an ordinary visit to an ordinary site.

2. 2

   The server relays to that real site

   The endpoint forwards the handshake to the genuine destination, so the certificate that comes back is that site's real certificate, validly signed, with a real Certificate Transparency history. No certificate was ever issued for the tunnel.

3. 3

   An authorised client proves itself in the handshake

   A client holding the operator's key embeds an authentication value inside fields the handshake already carries. There is no extra message and no additional round trip; an observer sees only the normal exchange.

4. 4

   The paths diverge

   Recognising a valid client, the server takes over the session and carries the tunnel. Seeing anything else — a browser, a scanner, a probe — it continues the relay, and the visitor simply reaches the real website.

The last two rows matter. REALITY is a strong answer to identification by handshake and by probing. It does nothing about an address that has been blocklisted for other reasons, and nothing about statistical analysis of how much traffic goes where. Any description that presents it as a complete solution is overstating it.

• The choice of borrowed site matters a great deal. It should be popular enough that traffic to it is unremarkable, plausible as a destination from the network in question, and reachable from the endpoint. A poor choice is itself a signal.
• There is an ethical dimension: the borrowed site's name is used without its involvement. It carries no traffic on your behalf beyond handshakes it was already prepared to serve, but it is worth being clear that this is what the design does.
• It does not protect against an operator who blocks the borrowed site outright, or against a network that permits only an explicit list of destinations.
• As with all such designs, it is a response to the classifiers that exist now. Detection research does not stop, and neither does the response to it.

The reasonable way to think about REALITY is as a substantial raise in the cost of identifying an endpoint, not as invisibility. It closes the certificate and probing avenues convincingly. The avenues it does not close remain open.