← askd

askd · state of the art

How askd compares, honestly.

Every tool here is good at something, and several are more mature than askd. This page sets out where askd genuinely differs, and where it does not, so you can judge the fit yourself. If you only want the short version, the summary is on the main page.

Proven parts, new combination

askd is built from primitives that have already survived the field, deliberately. Single Packet Authorisation has been in production since fwknop shipped it in 2004. Flat CA-signed credentials are the shape Nebula proved. Dial-out tunnels are what Cloudflare Tunnel and Teleport run at scale. Duplicate-send multi-path is long-settled practice in SD-WAN and MPTCP. Novelty can be a liability in security infrastructure, so every part here is one that has already been attacked by someone else first.

The contribution is the combination, in one small self-hostable binary: an SPA-gated silent port, a dial-out overlay with no inbound port, capability credentials, a relay that is blind to the traffic and to its own audit log, gap-free multi-path, and a hardware-rooted CA, with no third-party dependencies and no foreign control plane. Judged as a system rather than feature by feature, that combination is not currently occupied by anything else.

It also holds together better than the parts suggest. Three properties are worth naming, because they are what makes the combination a system rather than a pile of features.

Identity depends on no external service

A credential is a small CA-signed object that the relay verifies statelessly against a public key. Nothing is registered in any database. There is no identity provider, no SSO or SAML, no directory, no account store, and nothing to phone home to. The CA vouches once, offline, and from then on the credential is the authorisation. Issue one on an air-gapped machine and it works. The access proxies federate to an external IdP by design, and even self-hosted overlays keep a controller that has to be running and reachable to authorise a connection. askd has nothing to federate to, which is also why there is no account database to breach and no login service to take down.

It spans the layers instead of picking one

The trust root is physical, a hardware token or HSM you hold, and the CA key cannot be exported from it. Authorisation is a signed capability naming what may be reached, with a validity window. The reach it grants is address-shaped, a host and port bounded by the gateway's CIDR allowlist, the kind of thing you would normally need an L3 network for. And it is delivered as an ordinary L7 session under stock SSH, with no tun interface, no routes, no address plan and nothing in the kernel. The result is network-shaped reach without operating a network, and one chain from the token in your hand to the byte on the wire rather than four products integrated at the edges.

The resilience is a side effect, not a subsystem

Because the client owns the session and simply sends it across every relay path at once, failover needs no health checks, no leader election and no reconvergence. A relay dying mid-session costs nothing because the other copies were already in flight, and since each packet counts from whichever copy lands first, the measured latency tracks the better path: below either one where the relays are close, and equal to the best where one is clearly faster. Resilience falls out of the design instead of being bolted onto it.

At a glance

 askdTailscaleCloudflare TeleportWireGuardfwknopOpenZitiHeadscaleSSH + forwarded port
No inbound portsyesyesyesproxylistensSPA-gatedyesyeslistens
Silent to probes (SPA)yesnonononoyespartlynono
Self-hostable control planeyespartlySaaSyesyeslocalyesyesno control plane
Sovereign (no vendor in the loop)yesnonopartlyyesyesyesyesyes
Jurisdiction (applicable law)EUCanadaUSUSno vendorno vendorUSyoursyours
No middleman reads your trafficyesyesnonoyesyesyesyesyes, direct
Capability credentialsyesACLsyesyesnonoyesACL policykeys, not caps
Granular live cutyespartlypartlyyesnonoyesACL + key expiryper host, by hand
Hardware-rooted CAyesnonopartlynonopartlynoSSH CA + FIDO
Runs unprivileged (no root)yespartlyyesnopartlynopartlyneeds tun/CAP_NET_ADMINsshd as root
Sandboxed by defaultyesnononononononono
Gap-free multi-pathyesnononononopartlynono
Third-party dependenciesnonemanySaaSmanykernellibsmanymany (Go)none

Reading two of these columns.

SSH + forwarded port. askd is an ssh ProxyCommand, not a replacement, so the comparison is against the deployment people use instead: sshd exposed via a forwarded port. Ties are real. No vendor, so jurisdiction is yours; no third-party dependencies. What the exposure does not buy back:

  • Authorisation is a public key in authorized_keys. Scope is per host, not per capability; revocation is an edit on every host the key reached.
  • No single cut point. No way to drop one operator, one destination or one live session centrally.
  • Audit is host-local and writable by whoever holds root on that host. askd's ledger is sealed to an offline key the relay cannot read back.
  • One path. Link drops, session drops. askd duplicate-sends across relays; a session survives losing one.
  • Permanently reachable. sshd answers every scan. askd's relay port returns nothing without a valid SPA packet.

Headscale. Self-hosted Tailscale control plane (BSD-3), and the strongest answer to "self-host the coordination layer". It closes the sovereignty and jurisdiction gap outright, which is why it is in the table. Remaining differences are mechanical, not ideological:

  • Reachability model. WireGuard mesh with NAT traversal and DERP fallback: an overlay network with addresses, routes and a peer graph. askd brokers a single stream to one named service and assigns no address, so there is nothing to route from or mis-route to.
  • Enrolment, which both require. A Headscale node registers with the coordinator; an askd agent or operator is issued a CA-signed credential. Neither is zero-setup. The difference is what happens afterwards. Headscale's coordinator is online and in the path: it distributes keys, evaluates ACLs, and must be reachable for the network to function. askd's CA is offline and out of the path: it signs on a hardware token with no network involved and is never consulted again. The relay verifies the signature statelessly against a public key and holds no membership registry, no ACL database and no key material.
  • The whole credential lifecycle stays offline. Issuing a new credential, renewing one, or scoping a narrower one is a signature on an air-gapped token; nothing has to be reachable. Revocation needs no online authority either: credentials are time-boxed, and one can be cut immediately at the relay by fingerprint in a policy file that is re-read on every connect. No CRL, no OCSP, no directory to query. A Headscale deployment cannot enrol or re-key a node while the coordinator is down; an askd CA that is switched off is the normal state.
  • Planned, not shipped: the relay as a sealed dead-drop. Short-lived credentials are the right posture, but nobody hand-delivers one every morning, so in practice people issue year-long ones and lose the benefit to inconvenience. The intended design makes the short-lived case convenient without putting the CA online. The CA signs a batch offline on its token, seals each one to its recipient's key, and the operator uploads the batch. The relay stores opaque ciphertext: it cannot read a credential, forge one, or use one, and hands the current one over on request or in flight. The recipient unseals it and checks the CA signature before installing. A fully compromised relay leaks nothing and can only withhold, which is why expiry stays enforced by the verifier rather than by delivery. Marked because this page describes the roadmap as well as the current build; the table above is what exists.
  • Exposure. The coordination server is a listening HTTPS service. askd's relay is silent without SPA.
  • Authorisation. ACL policy evaluated by the coordinator against node identity. askd's authority is a CA-signed capability the relay verifies statelessly; the relay holds no policy database and no key material.
  • Trust root. No hardware-CA path. askd's CA key lives on a PKCS#11 token and never leaves it.
  • Privilege and surface. Needs a tun device (root or CAP_NET_ADMIN) and carries a large Go dependency tree. askd is a static binary, no tun, no third-party dependencies, seccomp and Landlock on by default.

Blue marks the tools that achieve a row; bold blue is askd. A single table cannot capture nuance, which is what the rest of this page is for.

What is actually exposed, precisely. The machines you are protecting expose nothing. An askd agent opens no port at all, so on the asset itself there is no socket to scan, no service to fingerprint and nothing to attack. The only listening socket in the whole system is the relay's single port, and that port is silent: without a valid signed knock it answers nothing, so a scan learns that something is listening and not one thing more. The knock transport is a deployment choice, not a fixed property of the design: run it over TCP where the network permits only outbound TCP through a proxy, or over UDP where you want no fingerprint at all, since an invalid datagram is dropped before anything answers. TCP is what ships today and UDP is the next transport, with the signed knock already sized to fit a single datagram. You pick whichever the network in front of you allows.

The asymmetry is the entire point. You move the exposed surface off hundreds of assets and onto one or two relays that hold no key, store no secret, read nothing, and can be rebuilt or replaced at will. Compromising a relay yields ciphertext and inconvenience, not access. Two hardened relays are a tractable defensive problem; two hundred internet-reachable sshd instances are not.

Against mesh VPNs

Nebula, Tailscale, WireGuard. These build a network; askd brokers access. That is the whole difference, and it cuts both ways.

Nebula

Closest peer on the credential model: flat CA-signed group-tagged certificates rather than X.509, self-hosted, one static userspace binary. Diverges at the layer.

  • Layer. Nebula is L3: overlay IP per node on a tun interface, UDP hole-punching between nodes, lighthouses for discovery. askd brokers a TCP stream to one service; no address, no interface, no route-table entry, no kernel involvement.
  • Traversal. Hole-punching needs UDP to pass. askd is egress-only TCP and works where UDP is blocked and inbound is impossible.
  • Exposure. Lighthouse is a listening UDP endpoint. askd's relay port answers nothing without a valid SPA packet.
  • Grant granularity. Nebula grants L3 reach to a host. askd grants reach to a named service.
  • Trust root. No hardware-CA path in Nebula.

Not a differentiator: blindness. A Nebula lighthouse never sees traffic either. "Our relay is blind" is a win over TLS-terminating proxies, not over Nebula. Against Nebula the real differences are the five above.

Tailscale

WireGuard mesh plus a coordination server. Stable overlay IPs, ACL-scoped visibility, and the best ergonomics in this table.

  • Control plane. Hosted, in a foreign jurisdiction, and not fully self-hostable. It can be revoked, subpoenaed or discontinued. Headscale recovers most of this; see the table.
  • Exposure. Coordination endpoint listens. No SPA.
  • Authorisation. ACLs evaluated against node identity by the coordinator, so the coordinator is in the trust path. askd's authority is a CA-signed capability the relay verifies statelessly.
  • Layer. L3 overlay with addresses, versus a brokered stream.

The trade is the coordination server: a control plane in a foreign jurisdiction that can be revoked, subpoenaed or switched off, which you cannot fully self-host. Headscale recovers much of that, at the cost of running an unofficial control plane.

WireGuard

The crypto floor most of this table stands on: kernel-level encrypted tunnels, fully self-hosted, no vendor. Not a competitor so much as a component.

  • Scope. Transport only. No discovery, no identity, no access control. Those are yours to build.
  • Exposure. Listens on a UDP port; visible to a scanner.
  • Reachability. Still needs one side to have a reachable address, which is the problem askd exists to remove.

Against access proxies and platforms

Cloudflare Access, Teleport

Identity provider plus proxy, usually on a SaaS control plane. Covers SSH, Kubernetes, databases and web, with session recording, RBAC and MFA.

  • Termination. The proxy decrypts to inspect and record. Not a flaw, a requirement: you cannot record a session you cannot read.
  • Consequence for askd. Opposite bet, opposite limits. A blind relay cannot offer session recording, and does not claim to.
  • Control plane. SaaS, foreign jurisdiction, not self-hostable in the Cloudflare case; Teleport self-hosts at the cost of running the platform.

OpenZiti

The closest architectural peer. Open source, outbound-only "dark" services with no inbound port, self-hostable controller and routers, application-to-application encryption so routers stay blind. The same core bet as askd.

  • Exposure. Public routers listen and authenticate with mTLS. askd's relay returns nothing without a valid SPA packet.
  • Stewardship. US company. Relevant to jurisdiction, not to code quality.
  • Trust root. Not hardware-rooted.
  • Footprint. Controller, routers and a large dependency graph versus a sub-1 MB static binary with no third-party dependencies.

NetBird

The closest European peer. Berlin-based, BSD-licensed, open, self-hostable, zero-trust. Matches askd on EU basing and sovereignty, so the differences are structural rather than jurisdictional.

  • Shape. WireGuard mesh you join, increasingly offered as a managed network. askd is relay-first dial-out with no network to join.
  • Exposure. Mesh endpoints listen. askd's relay is SPA-gated.
  • Trust root. No hardware-CA path.
  • Footprint. Sub-1 MB static binary, zero third-party dependencies.

Against privileged-access management

CyberArk, BeyondTrust, Delinea. This is the comparison that most clarifies what askd is, because the two make opposite bets about the middleman.

  • PAM model. Central vault holds every privileged credential and rotates it so no human knows it; the broker opens the session, injects the credential and records the keystrokes. All of that requires plaintext at the broker. Deliberate and defensible: an all-seeing middleman in exchange for control, attestation and recording.
  • askd model. The relay opens no port, holds no secret and sees nothing. Capability-scoped reach plus a tamper-evident metadata trail. No credential vaulting and no session recording, because a blind relay cannot provide either.
  • Not a spectrum. These are incompatible bets about the middleman, not points on a scale. Pick by which property you need.

If your compliance regime requires a recorded, replayable session, you need a PAM or a platform, not askd. If your requirement is that nobody in the middle can read the session at all, a PAM cannot give you that, and askd can.

Against single-packet authorisation

fwknop

The reference SPA implementation, in C, since 2004, widely deployed and actively maintained. askd's knock is the same idea, and fwknop had it first.

  • What the knock buys. fwknop opens the real firewall to the real service: post-knock you hold a socket to sshd. askd's knock opens a blind relay only, so the target still has no inbound port at any point.
  • Privilege. fwknop manipulates the firewall and needs root. askd's agent runs unprivileged, seccomp and Landlock confined.
  • Authorisation. Shared key, no capability model. askd carries a CA-signed capability naming what may be reached.
  • Absent by design in fwknop. No relay, no multi-path, no sealed audit.
  • Transport, and it cuts both ways. UDP vanishes from a scan but requires UDP egress. TCP survives the corporate network that permits only outbound TCP through a proxy, which is why askd uses it today. Transport is pluggable; UDP is next, so the deployment picks what its network allows.

When askd is the right choice

askd is built for a specific shape of problem. It fits when:

  • The machines must expose nothing. Targets sit behind NAT, CGNAT or a firewall you do not control, and opening an inbound port is either forbidden or a risk you refuse to take.
  • The network is hostile to overlays. Outbound TCP is all you get, UDP is blocked, and peer-to-peer hole-punching simply does not connect.
  • Nobody in the middle may read the session. Not the relay operator, not the host it runs on, not you. The relay forwards bytes it cannot decrypt.
  • Sovereignty is a requirement, not a preference. You need the whole substrate self-hosted under European law, with the trust root on hardware you hold and no vendor control plane anywhere in the path.
  • Access must survive infrastructure moving underneath it. Sessions ride several relays at once, so losing one mid-session costs nothing.
  • You want to keep the tools you have. askd sits under stock SSH as a ProxyCommand, so your keys, config, scp, rsync and port-forwarding keep working.

If instead you need a full L3 network between many nodes, or recorded and replayable sessions for a compliance regime, that is a different job and a heavier tool does it better. askd stays deliberately small.

The gap askd fills

Between fwknop, which is a firewall knock and nothing more, and Tailscale or Teleport, which are platforms you adopt wholesale, there is an unoccupied space: an open, self-hostable, dependency-free tool that combines SPA invisibility, a blind dial-out relay, capability credentials and gap-free multi-path, sitting underneath stock SSH rather than replacing it.

The two properties that pin it down: askd is the only one here that is both in the path, so it works through hostile egress-only networks where peer-to-peer meshes cannot, and blind, so unlike the proxies that manage the same trick it never reads what it carries. OpenZiti is the only other tool that holds both, and it is a large US fabric rather than a small European binary.

The honest summary: pick askd when you want reachability without a network and without a middleman who can read you, self-hosted, under European law. Pick almost anything else here if you want breadth, maturity, or a product you can buy.