Status: v1 complete and working — opt-in via ALPHACLAW_TLS_ENABLED;
PR #276 open for
review/merge. Deferred v2 items below remain deferred.
Stage: implementation done → PR review / merge (not scaffolding).
Last re-verified: 2026-07-24 (pytest green on this machine).
Date: 2026-07-24 (scaffolding), updated same day (full wiring), re-verified
2026-07-24 (stage + Slowloris hardening committed locally).
Branch: security/alphaclaw-tls-proxy-scaffold (PR #276)
Companion orama-system PR: security/02-peer-mesh-auth-tls-v2-plan
(stacked on PR #197), which ingests 3 security-hardening design docs and
records the full plan canonically at
orama-system/docs/v2/49-peer-mesh-auth-tls-v2-plan.md
(once merged; branch link until then).
Yes — when explicitly enabled. ALPHACLAW_TLS_ENABLED defaults off; with
it unset, bootstrap_alphaclaw() keeps plain http:// gateway URLs (by design).
| Check | Result |
|---|---|
pytest tests/test_alphaclaw_tls_proxy.py |
9/9 passed |
pytest tests/test_alphaclaw_manager_tls_wiring.py |
12/12 passed |
| Cert persistence + TOFU pinning | Covered by proxy tests |
bootstrap_alphaclaw() → https:// when env on |
Covered by wiring tests |
| TLS failure → graceful HTTP fallback | Covered by wiring tests |
| Malformed chunked body → HTTP 400 | Covered (review follow-up, on branch) |
| Stalled-client / Slowloris mitigation | 3bb36c8a — on origin as of 2026-07-24 |
Not live-validated here: a running AlphaClaw process with
ALPHACLAW_TLS_ENABLED=1 against a real gateway on this machine (unit/e2e
tests use fake upstream servers only). That is the remaining manual smoke
step before calling it "production-ready."
Tracker: item-level checklist lives in
docs/next/2026-07-25-pending-work-tracker.md §1 (kept in sync with this
note).
3bb36c8a (Slowloris fix) and 7dd01a76 (identity-audit lessons) are both
on origin/security/alphaclaw-tls-proxy-scaffold as of 2026-07-24 — the
prior "local-only, not yet on origin" note above was stale; re-checked via
git log against a fresh git fetch. 7dd01a76 remains out of TLS scope
(identity-audit memory, not this proxy work) but is harmless riding along on
this branch.
A follow-up commit (7bed40ea) qualifies a lesson-wording claim CodeRabbit
flagged on review 4770121389 of PR #276 — also on origin.
- Merge PR #276 once review is clean (review 4769478731 and 4770121389 addressed; re-check for newer rounds).
- Manual smoke:
ALPHACLAW_TLS_ENABLED=1+ real AlphaClaw gateway on loopback. - Windows ACL enforcement for cert store — minimal implementation
done per the plan at
2026-07-24-plan-windows-acl-alphaclaw-tls-proxy.md:_secure_path()+ pywin32 (SetNamedSecurityInfo, not the deprecatedSetFileSecurity) with anicaclssubprocess fallback, all 7 call sites replaced, 8 new unit tests (mocked win32security), 17/17 tests green. Not yet verified on real Windows hardware — needs manual verification per the plan's §5.2 on both the current RTX 3080 Windows machine and the incoming RTX 5080 replacement before this is trusted in production. Also still open: confirminghasattr(win32security, "PROTECTED_DACL_SECURITY_INFORMATION")on the actual target pywin32 build (plan §Provenance note), and addingpywin32to the Windows install path. - v2 deferred (see below): admin-pinned fingerprints, rotation policy, mTLS, auto-enable.
- Companion orama doc merges with
security/02-peer-mesh-auth-tls-v2-planwhen that stack lands.
This note is intentionally NOT a new ADR — per docs/adr/ADR-004's own
header, PT's ADR files are generated pointers to orama-system's canonical
docs/v2/ collection (zero-fragmentation doctrine: one source of truth,
not a parallel PT-side design doc). The full architecture decision lives
in the orama doc above; this file is a working note for the PT-side
implementation only, until/unless the orama doc's own maintainers decide
this warrants a synced ADR pointer.
orchestrator/alphaclaw_tls_proxy.py — a local-only (127.0.0.1-bound)
HTTPS reverse proxy that terminates TLS in front of AlphaClaw's existing
HTTP-only gateway. Real features, not stubs:
- Certificate generation + persistence. A self-signed cert is generated once and reused across restarts (regenerated only when missing or within 7 days of its 365-day expiry) -- a fresh cert every process start would make fingerprint pinning meaningless.
- TOFU fingerprint pinning. First start pins the cert's SHA-256
fingerprint; every subsequent start verifies it hasn't changed, raising
AlphaClawCertFingerprintMismatch(a real MITM-detection signal, never silently auto-repinned) if it has. - Real TLS termination + forwarding, verified end-to-end with a genuine TLS handshake against a genuine fake-upstream HTTP server.
- Stalled-client bounds (2026-07-24):
_ProxyHandler.timeoutwired toproxy_timeout;ThreadingTCPServer.daemon_threads = Trueso a hung handler cannot blockstop()or process exit (3bb36c8a).
orchestrator/alphaclaw_manager.py — wired in via
alphaclaw_tls_enabled() (env gate, ALPHACLAW_TLS_ENABLED, matching
dangerous_workers.py's established truthy-parsing convention) and
_maybe_wrap_gateway_with_tls(), called from bootstrap_alphaclaw()'s
own success path. This is the only place gateway_url's scheme is
ever decided — AlphaClawState and RuntimePayload both gained
tls_enabled/tls_fingerprint fields so orama-system can see whether
TLS is active, but orama never decides to use it; it only ever reads
whatever PT already resolved. This is the direct, working implementation
of the architecture invariant this whole exercise was about: PT is
authoritative for gateway discovery, route choice, topology, and
readiness; orama-system makes zero gateway decisions.
Why it lives in orchestrator/, not a new packages/ package: the
original design sketch (in the 3 ingested plan docs) proposed a standalone
packages/alphaclaw-tls package. Checking orchestrator/alphaclaw_manager.py's
own docstring first (its explicit architecture invariant, quoted above)
showed that invariant would be violated by a separately-versioned
package -- whether/how to expose AlphaClaw's gateway is exactly the kind
of decision that module already owns exclusively. Reconciled by placing
this module alongside it, and by making bootstrap_alphaclaw() itself
the only call site that ever touches gateway_url's scheme.
- No admin-pinned fingerprints (
PEER_PINNED_FINGERPRINTS-style pre-seeding) — TOFU-only for now, matching the plan's own v1 scope - No certificate rotation policy beyond the fixed 365-day expiry check
- Not auto-enabled by default (
ALPHACLAW_TLS_ENABLEDopt-in) — matching the plan's "existing deployments" answer (v1 warns/opts-in, never enforces) - Windows ACL enforcement for the cert/key/fingerprint store — minimal
implementation landed (
_secure_path(), pywin32 + icacls fallback, 7 call sites, 8 unit tests). Plan:2026-07-24-plan-windows-acl-alphaclaw-tls-proxy.md. Still open: real-hardware verification on the current RTX 3080 Windows machine and the incoming RTX 5080 replacement (plan §5.2), confirmingPROTECTED_DACL_SECURITY_INFORMATIONavailability on the actual pywin32 build in use, and addingpywin32to the Windows install path. - mTLS, audit logging, the pluggable auth-provider architecture (BUZZ/ Twitter/Google) — all orama-side and PT-side v2 work tracked in the companion doc, not started here
- Peer-mesh bearer-token TLS (the
query_peer_topology.pyside of the companion plan) is a separate surface, already landed independently on orama PR #197 as its own v1 minimum
- Code:
orchestrator/alphaclaw_tls_proxy.pyandorchestrator/alphaclaw_manager.py's own module/function docstrings point back to this file and the orama plan doc. - Tests:
tests/test_alphaclaw_tls_proxy.py(proxy internals: cert persistence, fingerprint pinning, real TLS forwarding, stalled-client bounds) andtests/test_alphaclaw_manager_tls_wiring.py(the actual wiring: env-gate behavior, no-op cases, real end-to-end gateway_url replacement, graceful degradation on failure) both point here. - orama-system side:
docs/v2/49-peer-mesh-auth-tls-v2-plan.md's "MVP wiring" section names this exact module by its intended path.