v1.10.0

Katacomb VPN 1.10.0

A desktop client for the Sentinel decentralized VPN network. Pick a node, pay for a
session on-chain, and tunnel through WireGuard, AmneziaWG, OpenVPN, V2Ray, XRAY or
Hysteria2.

1.10.0 is a feature release. AmneziaWG connections now use the AmneziaWG 3.1 protocol
tier when the node offers it, which encrypts the header of every packet and makes the
traffic harder to fingerprint. Nodes that do not offer it are spoken to exactly as before.
It also closes a gap where an updated helper could be left unused by an already-running
daemon.

Highlights

• AmneziaWG connections use the 3.1 tier where a node offers it. AmneziaWG 3.x
  encrypts the type field and header of every packet with a key the node hands out, adds
  random trailers and padding, and randomises timers, so the traffic carries less for deep
  packet inspection to match on than the 2.0 parameter set. This is a change to the wire
  format that no node can negotiate in-band, so nodes offer it as a second, opt-in tier.
  Today that means nodes running dvpnd with the tier switched on. Before an AmneziaWG
  handshake the app reads the node's public inbound list and asks for the tier if it is
  listed; a node that lists none, or that cannot be read in time, gets the same request
  as before and answers with the default tier. Either way the paid session is not at
  risk. The log line [session] AmneziaWG tier: says which tier a session landed on.
• Every other node is unaffected. The AmneziaWG device compiled into the privileged
  helper moved from amneziawg-go 0.2.19 to 3.1.20260828. With the 3.x keys unset, the
  3.1 engine's send and receive paths are the 2.0 engine's byte for byte, so the default
  parameter set every node hands out is framed exactly as it was. The container-based
  handshake test now builds its reference server from the same 3.1 commits dvpnd pins,
  with only the default parameters set, and passes.
• The new parameters are validated like everything else a node sends. The header
  protection key, the trailers flag, the MTU and the padding range are checked in the
  app's config guard and again in the root helper's own guard, and a malformed answer is
  refused before anything reaches root, with the session refunded. On the 3.1 tier the
  tunnel MTU comes from the node's answer instead of the path measurement, because the
  tier's prefixes, trailers and padding take room out of every packet.
• The helper is checked on every start, daemon or not. The check that compares the
  bundled helper with the installed one used to be skipped whenever the root daemon's
  socket existed. A newer app on a machine with an older daemon then ran with the old
  helper: it accepted the app's operations but validated configs against its old
  allow-lists, and refused a correctly built config as root only after the session was
  paid for. The check now always runs, and when it replaces the helper it also restarts
  the daemon's service. On a packaged install the two helpers are identical and nothing
  is asked. This mostly affects builds from source on a machine that also has the .deb
  installed, which is how it was found.

Fixes in 1.10.0

• Speak the AmneziaWG 3.1 tier where a dvpnd node offers it

Known limitations

• A chain has a hard life of about two hours. Measured on mainnet: exit hops report
  no usage to the chain, so the exit's idle deadline is pinned at purchase and never
  moves, even while the entry still has quota. This is node-side behaviour, not a client
  bug, but it is yours to plan around.
• Chains can only be built from V2Ray and XRAY nodes. The other protocols have no
  equivalent of the relay mechanism a chain needs.
• Expect roughly 2 to 3 MB/s and a large latency increase on a chain. Chains are for
  privacy, not speed.
• Local-proxy mode tunnels only the apps you point at its SOCKS address. Everything else
  leaks, by design, and the kill switch does not apply.
• The TLS and Reality wrapping does not authenticate the node. There is nothing on chain
  to verify a node's certificate against, so an attacker on your local network can answer
  a handshake in a node's place.

Platform support

Linux x86_64 only. Tested on Debian 11+, Ubuntu 20.04+, and derivatives (Mint,
Pop!_OS, Zorin).

Installation

Recommended: .deb

sudo apt install ./katacomb-vpn_1.10.0_amd64.deb

Installs a root daemon, so connect and disconnect never prompt for a password. It needs
one log out and log back in after the first install before that takes effect.

Alternative: AppImage

chmod +x katacomb-vpn-1.10.0.AppImage
./katacomb-vpn-1.10.0.AppImage

No install needed. Every privileged operation prompts for a password instead.

Verifying your download

sha256sum -c SHA256SUMS --ignore-missing
gpg --verify SHA256SUMS.asc SHA256SUMS

Signed with key 740A F267 B0D8 162B E477 779D 7315 246A 6E67 F3C6. Import it first if
you have not already:

curl -sS https://keybase.io/trinitystake/pgp_keys.asc | gpg --import

Important

• Connecting spends real funds. Sessions are blockchain transactions priced in
  udvpn, and a failed connection is refunded automatically, but an expired one is not.
• AppImage on Ubuntu 22.04 and 24.04 needs libfuse2, or the
  APPIMAGE_EXTRACT_AND_RUN=1 workaround. See the README.
• AppImage on Ubuntu 24.04+ runs with the Chromium sandbox disabled. An AppImage can
  install neither an AppArmor profile nor a SUID sandbox helper, so prefer the .deb there.

Security model

Node operators are treated as adversaries. Everything a node sends is validated before it
reaches a privileged operation, because a VPN config can otherwise run shell commands as
root. See CLAUDE.md
for the full threat model and architecture.

License

GPL-3.0-or-later. Bundled binaries (v2ray, xray, hysteria) are under their respective
licenses. See
THIRD-PARTY-LICENSES.md.