Onion Reachability

Kicksecure ™

Download

On Computer USB Installation Intel / AMD64 ARM64 Raspberry Pi PPC64 Windows (VM) Mac Linux (VM) VirtualBox (VM) Qubes (VM) KVM (VM) Debian morph to Kicksecure More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Onion services can sometimes become unreachable even when the server configuration has not changed. Possible causes include Tor bugs, denial of service attacks, malformed service descriptors, problems with the local Tor daemon, and limitations in available debugging tools. This page documents known issues, investigation results, temporary recovery procedures, and related upstream bug reports.

User Documentation

Non-functional Onion Services

Tor Upstream Unfixed Denial of Service Issue

Tor upstream DoS issue attacker can force intro point rotation by ddos was reported by Tor developer Roger Dingledine. At the time of writing:

• Issue opened in 2018.
• Status: Open, Not Scheduled.
• Last comment by Roger Dingledine in 2023.
• Last ticket status change to Not Scheduled in December 2025.

Malformed Hidden Service Descriptor Issues

All were unresolved at the time of writing in July 2026.

• https://gitlab.torproject.org/tpo/core/tor/-/issues/41094
• https://gitlab.torproject.org/tpo/core/tor/-/issues/41016
• https://gitlab.torproject.org/tpo/core/tor/-/issues/41101

General Bad State of Tor Onions

Tor onions are generally in a bad state. This is unspecific to Kicksecure or Whonix.

Vanguards is a software project by The Tor Project (TPO) / Tor developer Mike Perry. Quote from The Vanguards Onion Service Addon:

Even after deployment of the new v3 onion service protocol, the attacks facing onion services are wide-ranging, and still require more extensive modifications to fix in Tor-core itself.

Because of this, we have decided to rapid-prototype these defenses in a controller addon in order to make them available ahead of their official Tor-core release, for onion services that require high security as soon as possible.

For details about the defenses themselves, please see README_TECHNICAL.md.

For additional security information, please see README_SECURITY.md.https://github.com/mikeperry-tor/vanguards

A very comprehensive bug report was submitted by an advanced user in 2022.

In the same year, 2022, Tor developer Mike Perry provided rare and detailed insights into the funding and development issues of Tor onions.

We have been seeing sustained attacks from multiple adversaries against onion services, and against the Tor network itself, for the past 3 months. These adversaries are continually adapting to our defenses.

For the past 3 years, we have attempted to get funding for DoS defenses for onion services from various funding sources. Every single one of these funding sources declined to fund onion service development or defenses. Because of the way our funding model works, this proposal-reject churn also delayed development on other tasks. Effectively a DoS attack in and of itself.

During this process, one of the two primary developers on onion services resigned. The other primary onion service developer is currently on leave. In fact, we will only have 2 developers directly devoted to all of C-Tor for the next 6-8 weeks or so, and about half of that developer time will be spent writing and revising other funding proposals during this period. The remainder will be spent performing other already funded work, and related administration tasks.

We do have pending funding for general DoS defenses that should be finalized soon, but that also does not cover onion service development. We will need to show other progress for that funder; any DoS defenses specifically for onion services will still have to be done "on the side".

Normally, I would not air our dirty laundry like this, but since it will have a direct impact on people like you, it seemed important to explain why we're going to be especially unresponsive to issues with onion services for the next while.https://github.com/mikeperry-tor/vanguards/issues/91#issuecomment-1228698338

As per the Vanguards commit history, the last substantial code change in Vanguards happened in 2021. There were some minor commits in 2023, but these were only related to Dependabot.

A Vanguards issue was reported to TPO in November 2023, was assigned, but stalled.

More tickets with zero replies:

• Vanguards issue #100
• Vanguards issue #99

There was a Tor Project fundraiser in 2023.

The Tor Project published a roadmap for improving onion support.

A number of open tickets are related to onion service stability:

• Understand code performance of onion services under DoS (#33704) - Tor
• Research approaches for improving the availability of services under DoS (#31223) - Tor
• Attacker can force intro point rotation by DDoS (#26294) - Tor
• DoS resistance measures from C Tor (#351) - Arti
• No attempt was made to write an exhaustive list.

The Tor Project's focus seems to have since shifted to onions in Arti.

See Announcing Vanguards for Arti.

Arti's Vanguards implementation is based on the research behind Tor's Vanguards add-on, and offers similar protections to its Vanguards component.https://blog.torproject.org/announcing-vanguards-for-arti/

The other experimental defenses from the add-on are not yet implemented in Arti (but they are on our roadmap!)https://blog.torproject.org/announcing-vanguards-for-arti/

Lack of Onion Reachability Debugging Tools

A Tor v3 onion connection is two independent 3-hop circuits meeting at a rendezvous point (RP), split across two daemons on two hosts, with cached state and rate-limited observation. From the outside almost every failure looks identical: a connect just "hangs" or "fails". Each question below isolates a different failure stage, and the difficulty is nearly always the same shape: how do I observe one stage without the other stages masking what it is really doing?

Fault attribution: is it me or the service?

Question	Why it is hard	Planned Tool(s)
Whose fault is a failed connect -- my client Tor, the network, or the service?	The single hardest question: all three produce the same "it does not load".	onion-preflight (isolates client-vs-onion via external control onions), tor-client-health
Can my local Tor reach relays at all, or is my guard set dead?	A degraded or 0-up guard set is a client fault masquerading as an onion outage.	tor-client-health (DEGRADED on 0 guards)
Is the break in the client's own 3 hops, or beyond the rendezvous point where I can never see?	On the real internet each side sees only its own three hops.	onion-connect-trace (client leg), onion-control-snapshot --paths (service leg), onion-e2e-path (stitches both on a same-host repro)
Which exact stage did the connect die at -- descriptor / intro / rend / service?	"Failed" is not a stage. SERVICE = rendezvous done, far side refused at app/port level, a wholly different bug from "intro did not answer".	onion-connect-trace (stage classifier), extended SOCKS 0xF0-0xF6

Descriptor problems (the stale-cache trap)

Question	Why it is hard	Planned Tool(s)
Is the descriptor published on the hashring now, or am I clinging to a cached one?	Two different truths, and the warm-client cache hides the difference.	onion-desc-fetch (live HSFETCH), onion-desc-inspect (cached copy)
Am I hitting the tor#25882 refetch-stall (warm client, stale descriptor, dead intro points)?	A fresh client works while the warm one fails, so it will not reproduce after a restart.	onion-preflight REFETCH HEAL TEST (heals => stale-descriptor class; still fails => intro points genuinely dead)
How do I view the descriptor, its revision counter, and which dead intro relays the client held?	The forensic state lives encrypted in the client's cache.	onion-desc-inspect (revision counter, lifetime, single-onion, PoW, intro set; --ns marks NOT IN CONSENSUS)
Is my clock skewed outside the descriptor validity window?	A silent skew makes a perfectly-published descriptor look absent.	clock-drift-check (independent online clock vs local)

Split-brain (two Tor daemons, same identity)

Question	Why it is hard	Planned Tool(s)
Are two Tor daemons publishing the same identity key and competing on the hashring?	Intermittent by nature: a client hits a "wrong" HSDir only sometimes.	onion-splitbrain-check (fans HSFETCH to every responsible dir)
Is it a REAL persistent split, or benign republish lag caught mid-flight?	A normal republish makes old+new descriptors coexist transiently, so one sweep is never proof, and C-tor rate-limits per-HSDir requeries ~15 min.	onion-splitbrain-corroborate (spaced sweeps: PERSISTENT vs FLAPPING vs UNDER-SAMPLED)

DoS / introduction flood

Question	Why it is hard	Planned Tool(s)
Would we detect an introduction flood (tor#26294) before reachability degrades?	The preflight path only points at the stats tool; it does not itself alarm, so a flood erodes reachability invisibly.	onion-hs-stats (INTRODUCE2 rate, PoW verify-fails/replays, PoW-queue trim, est_hours_to_force_intro_rotation dropping below intro lifetime)
Is the service silently running on a degraded intro-point set?	Fewer live intro points than configured shrinks reachability before it fully breaks.	onion-intro-watchdog

Server-side intermittent disruption

Question	Why it is hard	Planned Tool(s)
Is our own server's uplink intermittently killing OR-connections?	Intermittent, gone by the time you look, and indistinguishable from a healthy circuit in any point-in-time snapshot.	tor-orconn-watch --follow (live flap/reset/extend-fail timeline), tor-orconn-watch cron */5 (joined with host NIC/TCP counter deltas)

Reachable-but-wrong (the false green)

Question	Why it is hard	Planned Tool(s)
Is a web onion reachable but serving the wrong thing -- a 502/503, the default vhost, or an empty reply after a good rendezvous?	A completed rendezvous only proves the tunnel is up; nginx can still answer with an error page, the wrong server block, or nothing at all, and a plain reachability probe passes it clean.	onion-preflight (HTTP end-to-end gate), onion-mail-probe --direct (local :74 HTTP stub vs the onion's :80)
Is a mail onion reachable but not actually replying correctly?	Same trap for mail: a port can accept TCP yet give no valid greeting, or refuse at the app level after a good rendezvous.	onion-mail-probe (POP3 +OK / IMAP * OK / SMTP 220; --direct separates "backend down" from "onion path broken")
Does any .onion request get redirected to the clearnet host?	A correctness and deanonymization bug that a plain reachability check passes clean.	onion-redirect-test

Planned Tools

General tools:

• onion-socks-probe -- raw SOCKS5 CONNECT reachability probe (real onion REP byte).
• onion-desc-fetch -- is the descriptor PUBLISHED on the hashring right now (HSFETCH)?
• onion-desc-inspect -- decrypt/print the client's CACHED descriptor (intro points, revision, PoW).
• onion-connect-trace -- client-side sidecar timeline: stage reached + the client's own 3 hops.
• tor-client-health -- client Tor health (bootstrap, guards, consensus validity window).
• onion-splitbrain-check -- two daemons publishing the SAME identity key on the hashring?
• onion-splitbrain-selftest -- mock-control-port selftest for the split-brain detector.
• tor-orconn-watch -- server-side OR-connection disruption (live --follow or cron sample).
• clock-drift-check -- online-vs-local clock delta (a skew breaks descriptor windows).
• onion-control-snapshot -- service-side intro/guard/liveness snapshot (--paths: service's 3 hops).
• onion-intro-watchdog -- detect a DEGRADED intro-point set (+ optional remediation).
• onion-hs-stats -- onion health / anti-DoS stats (intro rate, PoW, upload freshness).
• onion-hostname -- print an instance's .onion hostname.

Server specific tools:

• onion-preflight -- staged reachability diagnosis for ONE onion (+ refetch heal test).
• onion-e2e-path -- end-to-end hop-by-hop stitcher, both control ports (repro/same-host).
• check-onions -- sweep EVERY instance, run the matching preflight; non-zero if any fail.
• onion-probe-fresh -- probe via a FRESH, isolated Tor (onionprobe, ephemeral ports).
• onion-fail-capture / -all -- on-failure forensic capture into the onion-diag log.
• onion-rend-collect -- collect REND (degraded-descriptor) causes into the diag log.
• onion-circuit-rate -- rendezvous-circuit request rate per onion (from nginx logs).
• onion-redirect-test -- guard: a .onion request must never redirect to the clearnet host.
• onion-ipv6-ab -- TEMPORARY: surface the IPv6 A/B circuit-test result.

Local Tor Client Stall Bug

A relevant factor is the state of the Tor user's local Tor daemon.

It has been reproduced multiple times that an unreachable onion becomes reachable after restarting Tor. Similar reports can be found online.

When restarting Tor resolves the issue, this can almost always be considered a bug in Tor, as Tor should be able to recover without requiring a restart.

onionprobe can be useful for this purpose.

onionprobe

Whonix: onionprobe is incompatible with Whonix.

Debian, Kicksecure, etc.:

sudo apt update

sudo apt install onionprobe

Kicksecure:

onionprobe -e w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion

Whonix:

onionprobe -e dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion

Onion Domains by Other Projects

• Tails

• APT: use non-onion HTTPS sources for Debian repositories (tails/tails!383)

Closes issues:

• Fix failures with Debian's APT repository onion service (tails/tails#17993)

Commits:

• APT: use non-onion HTTPS sources for Debian repositoriesTails changelog

• Qubes onion and Debian onion issue user bug report

• Other projects with unresolved onion issues:
  • bitcoin.org onion domain connectivity issues
  • Lightning Network Plus onion service issue
    • Umbrel onion service issue
  • Start9 LND hidden service descriptor issue

Denial of Service Attacks against Tor and Onions Are Common

• 2021: https://forums.whonix.org/t/most-onions-down-due-to-a-denial-of-service-attack-on-the-tor-network/10979
• 2023: https://blog.torproject.org/tor-network-ddos-attack/

At some points, the attacks impacted the network severely enough that users could not load pages or access onion services.https://blog.torproject.org/tor-network-ddos-attack/

Non-Solutions

OnionBalance

• OnionBalance master domain periodically offline - error "Descriptor upload failed" (January 2026)
• Lacking Proof Of Work anti-DoS defense.

As of December 2023, it does not support the Proof Of Work anti-DoS defense (PoW), but this is being planned.https://onionservices.torproject.org/apps/web/checklist/#using-onionbalance

• Bug: OnionBalance issue descriptor loading error
  • OnionBalance issue Automatic Reupload Attempts for Failed Descriptors
  • Pull request: OnionBalance merge request Automatic Reupload Attempts for Failed Descriptors remains unanswered after 5 months.

Non-Issues

Docker

download.kicksecure.com / download.whonix.org are simple, with no Docker at all.

Tor Onions Outdated Cryptography

Does not support offline keys yet:

• https://onionservices.torproject.org/apps/web/checklist/#towards-offline-main-keys
• https://spec.torproject.org/rend-spec/protocol-overview.html#imd-offline-keys
• https://gitlab.torproject.org/tpo/core/arti/-/work_items/1194

Footnotes

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2026 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 14 year success story and maybe DONATE!