sec: the mTLS 9257 wallet transport dispatches custody and master-tier methods with no authz gate

[MichaelTaylor3d]

Task

The loopback mTLS 9257 listener serves the whole Sage-parity wallet surface with no wallet_authz gate at all, so every custody, spend and master-tier method is dispatched on possession of the shared client cert alone. It is not exploitable today only because the credential cannot be obtained; persisting the cert makes an ungated wallet surface live.

Context

• crates/dig-wallet/src/sage/transport.rs:213 build_router mounts POST /:method -> handle -> WalletBackend::dispatch directly. No token is read and no authorization is consulted, on either serve_mtls or serve_http/serve_dual.
• crates/dig-node-service/src/server.rs:2032-2043 spawns serve_mtls on 127.0.0.1:9257 on every node start (bind failure is non-fatal), so the route is live in production.
• Authentication is SharedCertVerifier (transport.rs:96): a client cert is accepted iff its DER equals the server's own. Possession of that cert+key is the entire credential.
• crates/dig-wallet/src/sage/service.rs:299 generates the cert fresh in memory each run and never persists or exposes it, so no client can currently present it. Its own comment anticipates that "a real deployment persists this so a client can read it" — that change alone flips this from unreachable to fully open.
• Contrast the two gated planes: server.rs:1086 (POST /{method}) and server.rs:1467 (/ws) both go through wallet_authz::authorize.

Found while closing the cross-plane escalation on PR #248 (a paired token reaching network::add_peer via the parity plane). Same class, third plane: the tier is a property of the capability, not of the transport it arrived on. #248 fixed the two token-bearing planes; this one uses a different credential and was left out of that PR's claim deliberately rather than silently — see the qualifier on pairing::revoke_paired_token.

Scope

Either apply wallet_authz inside transport.rs's handler (so one gate covers every route into dispatch), or make the absence structural and reviewable — e.g. the listener serves only the read plane. A test asserting that every route into WalletBackend::dispatch is gated is what stops a fourth plane appearing; a per-route test set cannot see this.

Do not treat the unobtainable cert as the control. It is a lockout, not a policy, and the one-line change that makes the transport usable is the same change that makes it exploitable.

Parent

https://github.com/DIG-Network/dig_ecosystem/issues/2870

[MichaelTaylor3d]

The generalizable half — "every route into X is gated" is not tested anywhere

Filing context so this ticket carries the pattern and not only the instance.

WalletBackend::dispatch is reached by three planes, and each was gated independently:

plane	gate
control.* HTTP + WS	control::requires_master_token
Sage-parity POST /:method + /ws	wallet_authz::authorize
mTLS 9257 (sage/transport.rs:213)	none

The third was invisible to two prior security audits — including one that specifically enumerated the doors — precisely because nothing asserts the set is complete. Each door was verified in isolation; the enumeration never was.

That is how the second plane survived too. PR #248 closed chiaPeers.add on the control plane, and a gate then found POST /add_peer reaching the byte-identical writer under master || is_paired. Same defect, same reason: a per-plane audit is structurally blind to a plane it does not know about.

So the durable fix is not "gate 9257" — it is a test that fails when a new route appears. Something that enumerates every mount reaching WalletBackend::dispatch and asserts each is behind a known policy, so a fourth plane fails the build instead of waiting for an audit to notice it. PR #248 added the_master_tier_is_a_property_of_the_capability_not_of_the_plane, which pins the control and wallet policies together; this wants the same shape one level up — pinning the set of doors rather than the policy behind each.

On the containment, stated precisely so nobody over-relaxes on it: 9257 is unreachable today only because service.rs:299 generates its client cert per run and never persists it. That is a real barrier and a paired token cannot supply the credential — but it is an accident of key lifetime, not an authorization decision, and the comment at service.rs:296 anticipates the change that would make it live. Anything that persists or shares that cert turns this into an unauthenticated custody surface with no further code change.

[MichaelTaylor3d]

Containment CONFIRMED by the re-gate — plus one residual that makes this strictly worse if wired

The 9257 mTLS door is genuinely unreachable today. Four independent checks, not one:

• SharedCert::generate() runs per process at sage/service.rs:299, and there is no fs::write anywhere — the cert never touches disk.
• client_identity_pem() has ZERO callers.
• SharedCert derives Clone only — no Debug, no Serialize — so it cannot leak into a log line.
• Loopback bind, plus a byte-identical client-cert verifier.

Reaching it requires a value that exists only in the process heap. So this correctly stayed out of scope for PR #248 and is not gating.

The residual, and it is the reason not to relax here

build_cors_router puts WILDCARD CORS over the same ungated router. serve_http / serve_dual / build_cors_router have no caller outside transport.rs, so it is latent rather than live — but if any of them is ever wired, it is strictly worse than the mTLS door, because a wildcard origin removes the one credential that makes the mTLS path unreachable.

And the module doc reasons "loopback only, so a wildcard origin is safe". Do not inherit that as an assurance. It is true of the current binding and says nothing about the router, which is the thing that would be reused.

So the fix here is still the enumeration test, not a patch

Nothing above changes the point already on this ticket: three planes reach WalletBackend::dispatch, each was gated independently, and nothing asserts the set is complete. The re-gate makes that sharper — enumerating by grepping every caller of dispatch found six doors in server.rs, not the four the PR narrative listed (:1117 JSON-RPC, :1363 POST /{method}, :1481 /ws, each with its transport pair). All six share one authorize, so the policy fix covered them — but the enumeration was wrong and nothing caught that either.

A test that fails when a new route into WalletBackend::dispatch appears would have caught the wallet plane, would have caught this, and would catch the next one.

[MichaelTaylor3d]

Owned by the key-custody/pairing/authz batch lane.

• branch: loop/batch-seckey (worktree dn-seckey, based on origin/main 3e480dd)
• draft PR: fix(security): gate the wallet transport and make the no-mint rule structural #452 (closes this ticket)

Progress will be logged here at each increment.

[MichaelTaylor3d]

Fix landed on loop/batch-seckey (PR #452)

The gate is now structural, not a per-route check.

dig_wallet::sage::transport::build_router takes an Arc<dyn WalletCallGate> as a required
parameter. There is exactly one handler behind POST /:method, and it calls
gate.authorize(&method, presented) before the body is interpreted — so a refused call has not
touched the db and has not built or broadcast a spend. serve_mtls, serve_http and serve_dual
all thread the same gate. The only gate the transport crate ships is DenyAll, so "no policy
wired" is expressible as a refusal rather than as an omission; an allow-everything double is
#[cfg(test)]-only and unreachable from a shipping call site.

The POLICY stays in dig-node-service, where the tier is known: wallet_mtls::NodeWalletGate
delegates to the same wallet_authz::authorize the HTTP and /ws planes call, so a third plane
cannot form its own opinion. server.rs constructs it from state.control_token +
state.state_dir at the wallet_mtls::spawn call site.

The test the ticket asked for.
every_route_into_dispatch_consults_the_gate_including_unknown_methods drives a recording gate
and asserts it was consulted once per call for a read, three custody mutations, a master-tier peer
alias, a retired custody name, and a_method_that_has_never_existed. The unknown name is the
load-bearing case: a per-route or per-method-list gate is satisfied by enumerating the methods
someone thought of, which is exactly how this plane came to serve the whole surface ungated.

a_denied_call_does_not_reach_dispatch asserts the refusal body is not the dispatch output —
status alone would pass against an implementation that dispatched first and rewrote the status
afterwards, which for submit_transaction would already have broadcast.

Revert-proof (measured). Neutering the gate call
(if false && !state.gate.authorize(...)) fails all three new tests: 9 passed; 3 failed.

Two notes on the ticket's measurements. The port is now 9776, not 9257 — origin/main
moved it under dig-node#260, and SAGE_RPC_PORT is pinned as a port this node must never bind. And
the ticket's "not exploitable today because the cert cannot be obtained" is exactly the lockout the
scope section says not to treat as the control: the one-line change that persists the cert is the
change that makes the transport usable, and it was the same change that made it exploitable.

SPEC.md §7.12 now states the obligation and requires it be enforced by construction.