Mirror Verification Workflow: Checking PGP Signatures, TLS Certs and Onion Format Before Login

The login form is already a failure. If you are staring at a username field on an onion you have not verified, the session is over. You just have not lost anything yet.

Phishing on hidden services does not look like a misspelled brand. It looks like the real page. The URL is a 56-character v3 onion. Humans cannot memorize that string. Attackers know it. They flood search engines and forums with clones that differ by a single character. Type a passphrase or a wallet PIN into the wrong one and the account is gone. This is a research-only workflow for checking a candidate mirror before you ever authenticate. It is not a map to live services, and it is not an invitation to log in anywhere.

The clone problem is mechanical

On the clearnet, a fake login often sits on a domain you can read. On Tor, a legitimate address looks like a random blob ending in .onion. A malicious twin looks the same to the eye. One published example of the trick is the difference between a prefix like expyuz5tat and expyuz5tbt. Same length. Same ending. Different site.

That is why search engines are a hostile index, not a directory. If you used a crawler to find a forum or a marketplace, treat the hit as untrusted until proven otherwise. Curated address books exist because the community got tired of watching people walk into clones. They are still a single point of failure. Treat them that way.

Onion format checks that actually catch fakes

Do this before PGP, before TLS, before you even think about a login box. Format is cheap. It eliminates a lot of junk in seconds.

A current v3 onion is 56 characters of base32, then .onion. The alphabet is lowercase a-z and digits 2-7. No 0, 1, 8, or 9. No uppercase. No underscores. If the string is 16 characters, that is old v2. Ignore it. If it has mixed case, odd punctuation, or a length that is not 56, stop. You are not looking at a normal v3 service.

Do not “glance” at two onions and decide they match. Open a text buffer. Paste the candidate. Paste the address from a signed source underneath it. Compare character by character. The phishing URL is built to survive a glance. It is not built to survive a diff.

Copy and paste only. Never retype an onion from memory, a screenshot, or a chat bubble. One transposed letter is a different hidden service. If you found the address in a search result, a random paste, or a “mirror list” with no signature, it is not an input to this workflow. It is bait.

Also check the URL bar after the page loads. Some clones redirect. Some serve a lookalike from a different onion than the one you entered. If the host changed, you are done. Close it.

PGP is the control. Directories are just a delivery method.

Tor.Taxi and Dark.Fail are not search engines. You do not query them. They are static address books that list PGP-verified onions for heavily trafficked forums, marketplaces, and related services. Dark.Fail is the older, text-heavy one. It tracks uptime and is supposed to hear about address changes directly from operators when a service rotates links to dodge DDoS. It is also a magnet for extortion and flooding, so it is often down. Ownership disputes have led to temporary compromises. That is not rumor. It is why “trusted directory” is not a substitute for cryptography.

Tor.Taxi showed up as Dark.Fail spent long stretches offline. Cleaner layout. Categories (marketplaces, forums, wallets, communications). It has been more resilient to DDoS in public reporting, and it also lists I2P endpoints. None of that makes it sacred. If someone owns the box that serves the HTML, they can swap every link on the page for a clone. The page is not the proof. The signature is.

The actual procedure is boring, which is why people skip it.

• The directory publishes a message that contains the current onion list.
• They sign that message with their private PGP key.
• You verify the signature against a public key you already trust.
• If the signature is valid, you have mathematical evidence that that specific list came from whoever controls that key. Not from whoever currently controls the web server.

Use the signed list. Do not use the clickable HTML as the source of truth. HTML is what an attacker edits first.

ASCII armor, fingerprints, and the fake-key attack

A signed announcement usually arrives as ASCII armor: a block of text starting with a header like —–BEGIN PGP SIGNED MESSAGE—– or —–BEGIN PGP SIGNATURE—–. That wrapping exists so you can copy binary cryptography through a text field. If you cannot paste a complete block, you cannot verify it. Truncation is a failure, not a maybe.

Verification has two layers people collapse into one. Layer one: the signature is cryptographically valid for some public key. Layer two: that public key is the operator’s real key. A valid signature on a fake key is a man-in-the-middle. Someone hands you a lookalike public key, you import it, and every “verified” mirror from that point on is theirs.

So you do not fetch a public key from the same page you are trying to audit. That is circular. You need key continuity. A fingerprint you recorded earlier, from an older signed message, from a second channel, from a previous session that you already verified. If this is the first time you have ever seen the key, you do not have a verification. You have a first observation. Treat it as weak until it matches independent copies.

I keep a local keyring and a short note of fingerprints. I do not re-import a directory key from the live site every visit. If the fingerprint changes, that is an incident. It might be a rotation they announced. It might be a takeover. Until you can prove which, you do not log in.

Never treat a green “verified” badge on a webpage as PGP. That badge is HTML. Run the check in software you control, on a machine you trust, against a key you already had.

Surface directories leak. Use them as a last resort, not a habit.

Clearnet fronts for these address books exist. They are convenient and they are loud. Your ISP can see the visit. A core OPSEC rule from people who actually use these directories for research: do not treat the surface proxy as a privacy tool. It is a pointer at best, and a logging point at worst. If you must consult a directory, prefer the onion, after you have a verified address for the directory itself. Same workflow, one level up. Yes, that is recursive. That is the job.

TLS certificates on hidden services are a double-edged check

Tor already encrypts the circuit. An extra HTTPS layer on an onion is optional. Operators add it anyway, often with a certificate from a public CA (Let’s Encrypt, Comodo, and the rest). That decision is useful to you as an investigator. It is also how sloppy operators burn themselves.

Public CAs log certificates in Certificate Transparency. Those logs are searchable. crt.sh is the usual interface. If a hidden service presents a cert, you can ask the logs who else has seen that cert, when it was issued, and what names it covers.

The failure mode SOS Intel has described is straightforward. If the same certificate is used on the hidden service and a clearweb server, the link is trivial. If the Subject Alternative Names include a clearweb domain, the link is also trivial. You did not de-anonymize anyone with magic. The operator published the binding in a public log.

For mirror verification, use CT the other direction.

• Note the certificate the onion presents. Issuer, serial, validity window, SANs.
• Search the logs for that serial or that public key.
• If SANs include a clearnet hostname you did not expect, you are not looking at an isolated hidden service. You are looking at dual-homed infrastructure, a leak, or a phishing box that reused a cert. Any of those is a reason to pause.
• If the cert is hours old and the service you think you are visiting has been around for years, ask why a brand-new cert appeared on this particular onion. Fresh certs are not proof of fraud. They are a question. Operators rotate. Phishers also issue.
• If there is no TLS at all, that is normal for onions. Do not invent a red flag out of a missing lock icon. The interesting case is TLS that points somewhere else.

Do not confuse “the padlock is present” with “this is the real host.” On Tor, the padlock means the browser accepted some certificate for this name. It does not mean the onion matches the signed list. PGP answers that. TLS answers a different question: what identity did this operator (or this phisher) attach in public CA infrastructure.

I also watch for mixed signals. An onion from a signed list that suddenly presents a cert bound to an unrelated commercial domain is not a comfort. It is a lead. Record it. Do not authenticate into it to “see what happens.”

A mirror verification workflow you can run in order

This is the sequence I actually use. Skip a step and you are guessing. Guessing is how clones eat credentials.

1. Isolate the session. Research only. No accounts you care about. No wallet that holds funds. Security level in Tor Browser at Safest if you are going to load anything untrusted at all. Do not download PDFs, office files, or binaries from a candidate mirror. Documents are a classic way to leave the onion and hit you on the real stack.

2. Format-check the onion. 56 characters, base32 alphabet, .onion suffix, no surprise redirects. Diff it against the signed source, not against your memory.

3. Verify the signed list, not the webpage. Import nothing blindly. Check the signature on the announcement. Check the key fingerprint against your prior record. If you cannot complete this step, you do not have a verified mirror. You have a URL.

4. Cross-check more than one signed source. A core rule: never trust a single point of failure. If Tor.Taxi and Dark.Fail both publish signed lists, they should agree on the address. If they disagree, one of them is stale, compromised, or looking at a rotation in progress. Disagreement is a stop, not a coin flip. Wait. Get another signed statement. Do not pick the link that loads faster.

5. Inspect TLS and CT if HTTPS is offered. Pull the cert. Search the logs. Read the SANs. Look for clearweb bindings and for a validity window that makes no sense. Write down what you saw. You will want that note if the same cert shows up on a different onion next month.

6. Only then consider loading the site, still without logging in. Compare the onion in the URL bar to the signed string one more time. If the page asks for a password, 2FA seed, or withdrawal PIN immediately, you are at the edge of the workflow. The verification is for not typing those things into a clone. It is not a green light to transact.

If a marketplace or forum rotates its onion after a DDoS, this is the window when fake mirrors spike. Directories try to update. Attackers try to update faster, in more places, with better SEO on the junk indexes. The signed message is how you tell those two activities apart. No signature, no rotation. Just a new trap.

What this does not buy you

A valid PGP signature on a link means that key holder published that onion. It does not mean the service is honest, solvent, or free of law-enforcement occupancy. Market admins lie. Directories go down. Dark.Fail’s history of DDoS and ownership mess is a reminder that popularity is a targeting package. Tor.Taxi being harder to knock over does not make its operators infallible. It makes the HTML more available. The cryptography is still the part that matters.

CT logs cut both ways. They help you catch a mirror that is glued to a clearweb name. They also help anyone else do the same to an operator who thought an SSL cert on an onion was free hardening. If you are doing OSINT on infrastructure, that leak is evidence. If you are trying not to get phished, it is a consistency check. Do not confuse those jobs.

Search engines will keep serving clones because the URL space is unreadable and the payoff is immediate: credentials, then coins. Directories will keep getting DDoS’d because they are the bottleneck people actually trust. Your job is not to pick a favorite bottleneck. Your job is to refuse to authenticate until the onion format is right, the signature verifies against a key you already had, the cert (if any) does not contradict the story, and two independent signed sources are not in a fight.

If any of those fail, close the tab. There is always another clone. There is not another passphrase once you typed it into the wrong box.