Mirrors: Understanding, Verifying, and Using Them Safely

What Are Mirrors?

A mirror, in the context of both the clearnet and the darknet, is an exact or near-exact replica of a website hosted on a different server or under a different address. The concept of website mirroring has existed since the earliest days of the internet. Software distribution sites such as the Apache Software Foundation and various Linux distribution projects have used mirrors for decades to distribute bandwidth load across geographically dispersed servers. The core principle is simple: multiple copies of the same content, hosted independently, so that if one copy becomes unavailable the others continue to serve users without interruption.

On the darknet, mirrors serve an even more vital purpose. Because Tor hidden services operate under conditions of heightened adversarial pressure, including denial-of-service attacks, law enforcement takedowns, and infrastructure failures, having a single point of access is a significant vulnerability. A site that operates only one .onion address can be rendered completely inaccessible if that single address is disrupted. Mirrors provide a fallback mechanism: if the primary address goes down, users can switch to an alternative mirror and continue accessing the service.

It is important to understand that a legitimate mirror is operated by the same entity that runs the original site, or at minimum is authorized by that entity. An unauthorized copy of a website that impersonates the original is not a mirror but rather a phishing site. The distinction between the two is the central security challenge that this guide addresses.

.onion Domains Explained

The .onion top-level domain is a special-use domain suffix that designates an anonymous hidden service reachable through the Tor network. Unlike conventional domain names, which are registered through ICANN-accredited registrars and resolved via the Domain Name System (DNS), .onion addresses are derived directly from the cryptographic keys that identify the hidden service. This means that .onion addresses are not human-readable in any meaningful sense; they are long strings of seemingly random characters.

In the current version of Tor hidden services (version 3), an .onion address is 56 characters long and is derived from the service's ed25519 public key. The address includes a checksum and a version number, which together allow the Tor client to verify that it is connecting to the correct service. This cryptographic binding between the address and the service's identity is a fundamental security property: if you know the correct .onion address, you can be confident that you are connecting to the server that holds the corresponding private key.

The previous generation of hidden services (version 2) used 16-character addresses derived from RSA-1024 keys. These have been deprecated since October 2021 because the shorter key length was considered insufficiently secure. All modern hidden services use v3 addresses exclusively. When evaluating mirrors, you should never trust a v2 .onion address, as the Tor network no longer supports them.

Because .onion addresses are cryptographically generated, anyone can generate a new one at any time by creating a new key pair. This is how mirror operators create additional addresses for the same service: they generate new key pairs and configure their Tor daemon to serve the same content on multiple .onion addresses. Each mirror has its own unique .onion address with its own key pair, but all mirrors serve identical content from the same backend infrastructure or from synchronized replicas.

For further technical reading on how .onion domains and Tor hidden services operate at a protocol level, the Tor Project maintains detailed specifications in its official Tor repository on GitHub, including the rendezvous specification documents that describe exactly how client-to-service connections are established.

Why Mirrors Exist

There are several practical reasons why darknet services maintain multiple mirror addresses. The most commonly cited reasons fall into four categories: resilience against DDoS attacks, censorship resistance, load distribution, and geographic redundancy.

DDoS Resilience

Distributed denial-of-service attacks are extremely common against high-profile darknet services. Attackers flood the hidden service's introduction points or the service itself with enormous volumes of traffic, rendering it inaccessible to legitimate users. When a service maintains multiple mirrors, a DDoS attack against one address does not necessarily affect the others, particularly if each mirror operates through independent Tor circuits and introduction points. This architectural separation allows users to simply switch to an unaffected mirror and continue using the service.

Censorship Resistance

While the Tor network itself is designed to resist censorship, individual hidden services can still be targeted. If an adversary manages to identify the physical server hosting a hidden service, they can seize it or force the hosting provider to take it offline. Mirrors hosted on different physical servers, potentially in different jurisdictions, make it significantly harder to eliminate a service entirely. As long as at least one mirror remains operational, the service continues to exist.

Load Distribution

Popular services can attract more traffic than a single server can handle. By spreading users across multiple mirrors, the service reduces the load on any individual server and improves response times for all users. This is functionally equivalent to how content delivery networks (CDNs) work on the clearnet, though the implementation details differ due to the constraints of the Tor network.

Geographic Redundancy

Hosting mirrors in different physical locations and with different hosting providers protects against localized outages, whether caused by hardware failures, power outages, or legal actions targeting a specific jurisdiction. This geographic distribution is a standard best practice in systems administration, and it applies equally to hidden services as it does to clearnet infrastructure.

PGP Verification of Mirrors

The single most reliable method for verifying the authenticity of a mirror is PGP (Pretty Good Privacy) cryptographic verification. PGP uses public-key cryptography to allow anyone to verify that a message or file was signed by the holder of a specific private key. In the context of mirror verification, the process works as follows:

1. The site operator publishes their PGP public key. This key is typically posted on the site's primary .onion address, on their clearnet presence if they have one, and often on public key servers. The key is identified by its fingerprint, a 40-character hexadecimal string that uniquely identifies the key.
2. The site operator signs a list of official mirrors. They create a plaintext document listing all current official mirror addresses and then sign that document with their PGP private key. The resulting signed message contains the original text plus a cryptographic signature.
3. Users verify the signature. Using the operator's public key, users can verify that the signed mirror list was genuinely created by the holder of the corresponding private key and has not been tampered with. If the signature verifies successfully, the user can be confident that the mirror addresses in the list are legitimate.

To perform PGP verification yourself, you need a PGP implementation such as GnuPG (GPG). The commands are straightforward. First, import the operator's public key with gpg --import operator_key.asc. Then verify the signed mirror list with gpg --verify mirror_list.sig mirror_list.txt. If GPG reports "Good signature," the list is authentic. If it reports "BAD signature," the list has been tampered with and should not be trusted.

The critical security assumption here is that you have the correct public key to begin with. If an attacker provides you with a fake public key, they can sign fake mirror lists that will appear valid. This is why it is important to obtain the PGP key from multiple independent sources: the primary .onion address, public key servers, trusted forums, and any clearnet presence the operator maintains. If the key is consistent across all these sources, you can be highly confident it is genuine.

The OnionShare project, an open-source tool for securely sharing files and hosting websites over Tor, provides an excellent practical example of how PGP signing is used in the Tor ecosystem. You can review their approach in the OnionShare GitHub repository, which includes signed releases and documentation on how to verify them.

How to Check if a Mirror Is Legit

Beyond PGP verification, there are several additional methods and indicators you can use to assess whether a mirror is legitimate. No single method is foolproof, so it is best to combine multiple approaches to build confidence.

1. Cross-Reference Multiple Sources

Never rely on a single source for mirror links. If you find a mirror address on a forum post, cross-reference it against the list published on the site's primary .onion address. Check whether the same address appears in the PGP-signed mirror list. Look for it on well-known darknet directories and link aggregation sites. If the same mirror address appears consistently across multiple independent sources, it is more likely to be genuine.

2. Check the SSL/TLS Certificate

While .onion addresses provide end-to-end encryption by default through the Tor protocol, some hidden services additionally deploy TLS certificates. If a site uses HTTPS in addition to the .onion encryption layer, you can inspect the TLS certificate to check whether it was issued to the same entity across all mirrors. Inconsistencies in TLS certificates between the primary site and a mirror should raise suspicion.

3. Compare Page Content and Behavior

Load the suspected mirror and the known legitimate site side by side (in separate Tor Browser tabs, for instance). Compare the visual appearance, the HTML source code, and the site's behavior. Phishing mirrors often contain subtle differences: modified login forms that send credentials to a third party, injected JavaScript for credential harvesting, or slightly altered page layouts. Pay close attention to the login page, as this is the primary target for phishing operators.

4. Verify the Canary or Warrant Canary

Some hidden services publish a regularly updated canary statement, a signed message affirming that the service has not been compromised or served with legal process as of a certain date. If the primary site has a current canary but the mirror does not, or if the mirror's canary is outdated, this may indicate that the mirror is not maintained by the same operator.

5. Monitor for Suspicious Redirects

Legitimate mirrors should not redirect you to different .onion addresses or clearnet URLs without explanation. If accessing a mirror causes unexpected redirects, especially to login pages or download prompts, treat the mirror as compromised and do not enter any credentials or download any files.

Community-maintained resources such as the Tor Project Community Forum and the Whonix Forums are valuable places to ask about specific mirror addresses and read reports from other users who have investigated their legitimacy.

Man-in-the-Middle (MITM) Risks

A man-in-the-middle attack occurs when an attacker intercepts the communication between two parties, potentially reading, modifying, or injecting content into the data stream without either party's knowledge. In the context of darknet mirrors, MITM attacks take on specific forms that users must understand and defend against.

Phishing Mirrors as MITM Proxies

The most prevalent MITM attack in the darknet ecosystem involves phishing mirrors that function as transparent proxies. The attacker sets up a server with its own .onion address and configures it to forward all traffic to and from the legitimate service. To the user, the phishing mirror appears to function identically to the real site: pages load, content is correct, and the site behaves normally. However, the attacker can inspect and modify all traffic passing through their proxy. When the user submits login credentials, the attacker captures them. When the user initiates a cryptocurrency transaction, the attacker can substitute the destination address with their own.

These attacks are particularly dangerous because they are difficult to detect. The phishing mirror serves real content from the legitimate site, so visual inspection reveals no differences. The only reliable defense is to verify that the .onion address you are using is one of the official mirrors, as confirmed through PGP-signed mirror lists or multiple independent trusted sources.

Exit Node Manipulation

While this risk does not directly apply to .onion-to-.onion connections (which remain within the Tor network and do not traverse exit nodes), it is relevant when accessing clearnet mirror lists or verification resources. Malicious Tor exit nodes can modify unencrypted HTTP traffic, potentially altering mirror lists, PGP keys, or other verification material served over plain HTTP. This is why you should always use HTTPS when accessing clearnet resources related to mirror verification, and why obtaining PGP keys from .onion addresses or key servers over encrypted connections is preferred.

DNS Poisoning and Redirection

For clearnet mirrors (regular domain names that point to Tor hidden services through reverse proxies), DNS poisoning is an additional attack vector. An attacker who can manipulate DNS responses can redirect users to a malicious server without altering the URL in the browser's address bar. This attack does not apply to .onion addresses, which bypass DNS entirely, but it is a significant risk for any clearnet-facing mirror or gateway service.

The Electronic Frontier Foundation provides extensive documentation on MITM attacks and encryption best practices through their Tor and HTTPS interactive diagram, which visualizes what information is visible to various adversaries at different points in a connection.

Video Resources

The following videos provide accessible explanations of Tor hidden services, .onion routing, and the broader context of darknet infrastructure. Understanding these fundamentals will help you better assess the legitimacy and security of mirror sites.

Further Reading and External Resources

The following resources provide additional depth on the topics covered in this guide. They include official documentation, open-source projects, community forums, and educational articles that will help you develop a thorough understanding of mirror infrastructure and verification practices.

Official Documentation and Projects

• Tor Project — Official GitHub Repository — The source code and protocol specifications for Tor, including the hidden service rendezvous specification that governs how .onion addresses work.
• OnionShare — GitHub Repository — An open-source tool for securely sharing files and hosting websites as Tor hidden services. Useful reference for understanding how hidden services are configured and how PGP signing is applied to releases.
• Tor Project — Onion Services Support — Official Tor Project support documentation covering the setup, operation, and troubleshooting of onion services.
• Tor Community — Onion Services Overview — A high-level introduction to how onion services work, suitable for those new to the technology.

Security and Privacy Resources

• EFF — Tor and HTTPS — An interactive visualization of what data is visible to different adversaries depending on whether you use Tor, HTTPS, both, or neither.
• Whonix Wiki — Onion Services — Detailed documentation from the Whonix project on hosting and connecting to onion services securely within a Whonix environment.
• Privacy Guides — Tor Overview — An independent, community-driven resource providing practical guidance on using Tor effectively for privacy protection.

Community Forums

• Tor Project Community Forum — The official community forum for the Tor Project, where users and developers discuss hidden service configuration, mirror verification, and security best practices.
• Whonix Forums — Community discussions about anonymity, Tor hidden services, and security practices within the Whonix ecosystem. A reliable place to ask questions about verifying mirror addresses.