felhom.eu/documentation/audits/RECON-subdomain-onboarding-2026-07-31.md

RECON — can a tester get a Felhom-issued subdomain instead of owning a domain? (2026-07-31)

Read-only. No customer, DNS record, tunnel, route or code change was created. Two hub login sessions were created (in-memory, 7-day expiry) to test cookie precedence; nothing else was mutated.

Headline: the product accepts a Felhom-issued subdomain today with no code change. The blocker is not Felhom — it is Cloudflare's edge certificate depth, proven live: a two-label hostname under a zone gets tls alert handshake failure and no certificate at all. Everything else follows from that.

---

1. Baselines — read fresh, none carried

What	Value	How
controller main	v0.188.0	HEAD=origin/main=4115e88, clean
controller on demo-felhom (9201)	0.187.0	pct exec 9201 -- cat /etc/felhom-controller-image
controller on demo-hp (9201)	0.187.0	same, on demo-hp
golden-baked controller	0.188.0 (sha 7353d8be…)	hub /configuration, selected option
agent published + vouched	0.119.0 (sha e37aca82…)	hub manifest; both boxes run 0.119.0
hub	0.84.0	deploy/hub image tag
ISO	v1.25.0 (scripts/iso/build-felhom-iso.sh:44); host-install v1.22.0	source read
felhom.eu HEAD	b4edc08	git rev-parse
MinAgent	0.113.0	hub /configuration

Both the hub (0.83.0→0.84.0) and the agent (0.118.1→0.119.0) moved since this morning's tester-gate run, which is exactly why the brief says to read rather than carry.

Not mine, left untouched: hub/internal/api/testdata/host-report.golden.json is dirty in the shared worktree — another session's WIP. Not staged, not reverted.

---

2. Question A — does the product accept a Felhom-issued subdomain?

2.1 The domain's full path, hop by hop

#	Hop	Citation	What happens
1	Operator form	hub/internal/web/configs.go:673	Domain: strings.TrimSpace(r.FormValue("domain")) — trimmed, nothing else
2	Hub DB	hub/internal/store/store.go:114	domain TEXT NOT NULL DEFAULT '' — no UNIQUE, no CHECK, no format
3	controller.yaml generation	hub/internal/configgen/configgen.go:48	setNested(base, []string{"customer","domain"}, cfg.Domain) — verbatim copy
4	Box pull	felhom-host-install.sh config-retrieve → /opt/docker/felhom-controller/controller.yaml	verified present on demo-felhom
5	Controller config load	controller/internal/config/config.go:363,379	env override FELHOM_CUSTOMER_DOMAIN; the only check is non-empty
6	Consumers	30 call sites (§2.3)	all plain string interpolation

2.2 Constraints found — the answer is "almost none"

• No format validation anywhere. Grepped the hub and controller for valid|regexp|match|check near domain: no hits on the customer domain.
• No registrable-domain / eTLD logic anywhere. grep -riE 'registrable|etld|publicsuffix' across both repos: zero hits. Nothing computes "the registrable part" of a customer domain.
• No "must not be a subdomain" rule. None exists.
• No uniqueness on domain. hub/internal/web/configs.go:644 rejects a duplicate customer_id only. Two customers may be given the identical domain string with no complaint (→ R-133).
• The only permissive-pattern check is the agent's internal/lanresolver/lanresolver.go:225 domainRe = ^[ \t]*domain:[ \t]*"?([A-Za-z0-9.-]+)"? — dots allowed, so a subdomain parses fine.

2.3 What consumes it on the box — all interpolation, no parsing

Surface	Citation	Shape
Controller Traefik route	controller/internal/infra/infra.go:214	Host(`felhom.%s`)
Wildcard TLS SAN	same, :217-223	main: "*.<domain>", sans: ["<domain>"]
App Traefik rules	catalog compose	Host(`${SUBDOMAIN}.${DOMAIN}`)
App env	controller/internal/stacks/manager.go:1187, deploy.go:560	DOMAIN=<domain>
Controller-host guard	controller/internal/web/server.go:571	controllerHost := "felhom." + domain
Report / DR recipe	controller/internal/report/builder.go:53	https://felhom.<domain>
FileBrowser	controller/internal/stacks/infra.go:157	domain passed to compose render
Share launcher, escrow, export, claim, data-path cards	9 further sites	template data only
SMB	controller/internal/infra/samba.go:65	NetBIOS name from smb.EffectiveServerName() — not the domain

None of these parse the domain. A dotted subdomain flows through every one of them unchanged.

2.4 Does anything assume the customer owns the zone? — Yes, but it is a switch, not a requirement

This is the question the brief flagged, and the answer is better than feared. The ACME challenge is config-selected at controller/internal/infra/templates/traefik.yml.tmpl:

certificatesResolvers:
  letsencrypt:
    acme:
      email: {{.ACMEEmail}}
{{- if .CFAPIToken}}
      dnsChallenge:
        provider: cloudflare
{{- else}}
      httpChallenge:
        entryPoint: web
{{- end}}

• With cf_api_token → DNS-01, which does need Zone:DNS:Edit for that zone, and the token is written to a 0600 .env on the box (controller/internal/infra/infra.go:123).
• Without it → HTTP-01, which needs no DNS credential at all.

The wildcard SAN is gated on the same flag: controller/internal/stacks/infra.go:211 — wildcardTLS := CFAPIToken != "" && Customer.Email != "".

Live on demo-felhom: DNS-01 is what actually runs — traefik.yml shows dnsChallenge: provider: cloudflare, a 0600 .env exists, cloudflared is up, and the dynamic route carries main: "*.demo-felhom.eu". So both demo boxes hold a zone-write Cloudflare token because they own their zones, not because the code demands one.

2.5 Does anything create DNS records automatically? — No

grep -rn 'dns_records' across both repos: zero hits. Neither the hub nor the controller ever creates, updates or deletes a DNS record. The two Cloudflare clients that exist are WAF-only:

• hub/internal/cloudflare/unblock.go — deletes [felhom-geo] WAF rules.
• controller/internal/cloudflare/{waf,geosync,zone}.go — reconciles [felhom-geo] WAF rules.

The cloudflared template says it outright: "Routes are configured in the Cloudflare dashboard (Zero Trust > Networks > Tunnels > Public Hostname)". All DNS and tunnel routing is manual operator work today.

2.6 Verdict on Question A

YES — the product accepts a Felhom-issued subdomain today, with no code change.

customer.domain = "t1.<felhom-owned-zone>" flows through the hub, controller.yaml, Traefik, the tunnel, app env and every URL builder without touching a single constraint. Nothing needs DNS API credentials if cf_api_token is left empty (HTTP-01), and nothing creates DNS records either way.

The blocker is elsewhere — see Question B.4. Two code-level caveats that are not blockers:

• Zone-resolution depth asymmetry (→ R-134). The controller's GetZoneID (controller/internal/cloudflare/zone.go:18) strips labels progressively (any depth). The hub's resolveZone (hub/internal/cloudflare/unblock.go:115) tries the exact name and then parentDomain — which strips exactly one label (:136). For t1.felhomcust.hu both succeed; for a two-label customer domain the hub silently fails to find the zone while the controller succeeds. Two implementations of one concept, disagreeing.
• Geo-restriction must stay OFF for shared-zone customers — Question D, and it is severe.

---

3. Question B — Cloudflare routing

3.1 How the demo boxes reach the internet

One tunnel per customer, created by hand. cf_tunnel_token is a per-customer field the operator pastes into the hub (hub/internal/web/configs.go:1338), stored in config_json.infrastructure, delivered in controller.yaml, and passed straight to cloudflared as TUNNEL_TOKEN (controller/internal/infra/templates/cloudflared-compose.yml.tmpl). If it is empty, cloudflared is simply not deployed — controller/internal/stacks/infra.go:67 logs "LAN-only node". The token is the entire config; there is no config.yml, and public hostnames live only in the dashboard.

3.2 The live DNS picture

felhom.eu            A     37.191.56.193          (NOT proxied)
hub.felhom.eu        CNAME dooplex.hopto.org →    (NOT proxied — no cf-ray, no server: cloudflare)
files.felhom.eu      CNAME dooplex.hopto.org
ep0.felhom.eu        A     167.233.158.164
demo-felhom.eu       (apex: no A)
felhom.demo-felhom.eu      188.114.97.0 / 188.114.96.0   (Cloudflare proxy)
poll.demo-felhom.eu        188.114.97.0 / 188.114.96.0   (Cloudflare proxy)
felhom.enkisfelhom.hu      188.114.96.0 / 188.114.97.0   (Cloudflare proxy)

All four zones (felhom.eu, demo-felhom.eu, enkisfelhom.hu, sajatfelhom.hu) sit on the same Cloudflare nameservers (martha/tony.ns.cloudflare.com) — one account.

Two facts that matter, both established rather than assumed:

1. felhom.eu is NOT behind Cloudflare. hub.felhom.eu and felhom.eu return no cf-ray and no server: cloudflare; they resolve through a DDNS name to a home IP and are served by DooPlex's k3s nginx ingress. The hub is not protected by, or reachable through, the tunnel fabric.
2. There is no *.felhom.eu wildcard today. A random label under felhom.eu resolves to nothing; the same probe under demo-felhom.eu and enkisfelhom.hu returns Cloudflare proxy IPs. So the cookie exposure in Question C is latent, not live — it becomes live the moment a tester box is put under felhom.eu.

3.3 Proxied wildcards — verified, not remembered

The brief warns against trusting a remembered plan restriction. Checked empirically: a random label under a customer zone resolves to Cloudflare proxy anycast IPs and returns a real HTTP response with server: cloudflare and a cf-ray. So a proxied wildcard DNS record works on this account today — the historical "wildcard proxying is Enterprise-only" restriction does not bind here.

Two wildcards in the same account already route to two different tunnels (each box runs its own cloudflared with its own token). Distinct wildcard records at distinct names (*.t1.zone → tunnel A, *.t2.zone → tunnel B) are ordinary DNS with no conflict.

3.4 The actual blocker — edge certificate depth

Proven live, and this is the finding that decides the shape of the whole plan.

The Cloudflare edge certificate for a zone covers exactly one wildcard level:

$ openssl s_client -connect poll.demo-felhom.eu:443 -servername poll.demo-felhom.eu
subject=CN=demo-felhom.eu
issuer=C=US, O=Google Trust Services, CN=WE1
X509v3 Subject Alternative Name:
    DNS:demo-felhom.eu, DNS:*.demo-felhom.eu

A two-label hostname resolves — the wildcard DNS record matches at any depth — but the TLS handshake is refused outright:

$ openssl s_client -connect zz.poll.demo-felhom.eu:443 -servername zz.poll.demo-felhom.eu
CONNECTED(00000003)
ssl3_read_bytes:tls alert handshake failure ... SSL alert number 40
no peer certificate available

$ curl https://zz.poll.demo-felhom.eu/
curl: (35) TLS connect error: ... tls alert handshake failure
$ curl https://poll.demo-felhom.eu/        # one-level control
HTTP 404                                   # TLS fine; just no tunnel route for a random name

Consequence. A Felhom-issued subdomain means customer.domain = t1.felhomcust.hu, so the controller lives at felhom.t1.felhomcust.hu and apps at poll.t1.felhomcust.hu — two labels under the zone. Under Universal SSL those hostnames get no certificate, and the tester's browser gets a hard TLS error before anything Felhom-related runs.

Options, in order of how much I can vouch for them:

Option	Cost	Status
Cloudflare Advanced Certificate Manager / Total TLS — issue *.t1.felhomcust.hu at the edge	paid add-on (~$10/mo, one zone)	Could not verify read-only — needs the dashboard or a token I am fenced from using. This is the single thing to check before committing to the plan.
One zone per tester	one domain per tester, ~2–4k HUF/yr each	Works today, no code change — but it is the cost the plan exists to avoid
Flat naming (poll-t1.felhomcust.hu)	—	Does not work without code change. The controller hard-derives felhom.<domain> (infra.go:214, web/server.go:571); every tester's controller would want the identical felhom.felhomcust.hu
Grey-cloud + DNS-01 wildcard on the box	—	Traefik can issue *.t1.felhomcust.hu itself via DNS-01, and the browser would see that cert — but grey-cloud means no tunnel, so the box needs a public IP and port-forwarding. Loses the reason the tunnel exists

3.5 What must exist for one tester box — the create-list

Assuming a Felhom-owned zone felhomcust.hu already on Cloudflare, and ACM/Total TLS confirmed:

#	Where	Action
1	Cloudflare → zone felhomcust.hu → SSL/TLS → Edge Certificates	Enable Total TLS / ACM so depth-2 hostnames get a cert. Verify first — §3.4.
2	Cloudflare → Zero Trust → Networks → Tunnels	Create tunnel felhom-t1. Copy its token (this is the cf_tunnel_token)
3	Same tunnel → Public Hostname	felhom.t1.felhomcust.hu → https://traefik:443 (or per the existing demo tunnels' pattern — I could not read those routes, §8)
4	Same tunnel → Public Hostname, one per app	e.g. poll.t1.felhomcust.hu → same origin. Cloudflare creates the proxied CNAME to <tunnel>.cfargotunnel.com automatically when you add a public hostname
5	Cloudflare → DNS (only if you prefer a wildcard over per-app entries)	*.t1.felhomcust.hu CNAME → <tunnel-id>.cfargotunnel.com, proxied. Verified workable in §3.3
6	Hub → Customers → + Add Customer	customer_id = t1; domain = t1.felhomcust.hu; email = the tester's real mailbox (see §6); DR tier / offsite per policy
7	Hub → the customer's Edit tab	Paste cf_tunnel_token from step 2. Leave cf_api_token EMPTY — §2.4 (HTTP-01), §5 (a shared-zone token is a cross-tenant write capability)
8	—	Do not enable geo-restriction for this customer. §5.

No DNS record and no tunnel is created by Felhom; steps 1–5 are entirely operator work in the Cloudflare dashboard.

---

4. Question C — cookies, CSRF, and the domain recommendation

4.1 The cookie, reconfirmed at source and on the wire

hub/internal/web/server.go:656-663 sets hub_session with Path: "/", HttpOnly: true, SameSite: SameSiteLaxMode, Secure: isSecure, no Domain, no __Host- prefix — as the brief states. Confirmed on the live production path:

set-cookie: hub_session=<REDACTED>; Path=/; Max-Age=604800; HttpOnly; Secure; SameSite=Lax

isSecure is computed from r.TLS != nil || X-Forwarded-Proto == "https". Over the k3s ingress that holds; over the plain-HTTP ClusterIP the same login returns the cookie without Secure.

4.2 What the hub does with two same-named cookies — tested, not reasoned

Against the live hub, GET /configuration, varying only the Cookie: header:

Cookie header	Result
hub_session=<real>	HTTP 200 — authenticated
hub_session=BOGUS; hub_session=<real>	HTTP 302 → /login — rejected
hub_session=<real>; hub_session=BOGUS	HTTP 200 — authenticated
hub_session=BOGUS	HTTP 302 → /login

r.Cookie("hub_session") returns the FIRST match in header order and never tries the others. A tossed cookie that sorts first therefore wins outright, and the real session is silently ignored.

Exploitability, stated precisely. Per RFC 6265 §5.4 a browser orders cookies longer Path first. Any page on any *.felhom.eu host can set hub_session=X; Domain=felhom.eu; Path=/configuration — a longer path than the real Path=/ cookie — so the browser sends the attacker's value first for every /configuration* request.

What that does and does not buy an attacker:

• It is not session takeover. The attacker cannot mint a value present in the hub's in-memory sessions map, so the tossed cookie never authenticates.
• It is a persistent, hard-to-diagnose denial of service against the operator UI, on paths of the attacker's choosing, invisible in the UI and not clearable from the hub.
• It fails closed on mutations. csrfToken(r) (server.go:698) reads the same first cookie and returns "", and validateCSRF (:678) returns false for an unknown session → 403.

4.3 What the CSRF defence actually rests on

A single choke point, and it is the token. hub/internal/web/server.go:256-269 gates every non-GET/HEAD/OPTIONS web route before the route switch, exempting only /login, isPublicBindPath, and the no-password-configured case. /api/v1/ is Bearer-authenticated and separately exempt. So the token is enforced on every mutating web route — the brief's worry that it "would be carrying the whole load" is correct, and it does carry it.

Measured, using POST /zz-recon-nonexistent so the CSRF gate is isolated with zero mutation (the middleware at :256 runs before the route switch at :271; a 404 therefore means "past the gate"):

Request	Result
session cookie, no _csrf	403 — CSRF enforced
session cookie, valid _csrf	404 — past the gate
Basic auth, no cookie, no _csrf	404 — CSRF SKIPPED
Basic auth + bogus cookie, no _csrf	403 — CSRF enforced

The third row is validateCSRF's documented early return: "No session cookie — likely Basic Auth or programmatic access; skip CSRF" (server.go:679-683).

Why that is a real hole and not just an API convenience (→ R-135). Browsers cache HTTP Basic credentials per origin and resend them automatically, including on cross-origin requests, and SameSite does not govern the Authorization header. So if the operator has ever authenticated to hub.felhom.eu with Basic auth in their browser, an attacker page anywhere — not merely same-site — can POST to any mutating hub route: the credentials ride along, auth passes, and CSRF is skipped because there is no cookie. The condition ("operator used Basic auth in a browser") is what makes this latent rather than live, and it is a condition, not a guarantee.

Note on SameSite=Lax: against a genuinely cross-site attacker it already blocks the cookie, so the cookie path is safe there. Against a same-registrable-domain attacker (tester.felhom.eu → hub.felhom.eu) Lax provides no boundary at all, and the CSRF token is the only thing left.

4.4 Should customer boxes live under felhom.eu? — No. And that is necessary, not sufficient.

I agree with the recommendation, for the stated reason, and it is cheap. A different registrable domain makes tossing structurally impossible, restores SameSite as a real boundary, and permanently answers "the tester owns no domain" for every future customer at one domain's annual cost.

But my findings say it does not finish the job, and the brief asked to be told if so:

1. Question D is not solved by moving zones — it is a shared-zone problem, and the new domain is a shared zone. The geo-WAF collisions in §5 apply identically there.
2. The nesting requirement collides with edge-certificate depth (§3.4). The separate domain forces two-label hostnames, which is precisely what Universal SSL will not serve. The separate domain makes ACM a prerequisite, not an optional extra. That is a real, ongoing cost the recommendation should carry openly.

So: adopt the separate registrable domain, and treat Cloudflare ACM/Total TLS on that zone as part of its price. If ACM turns out to be unavailable or unexpectedly expensive, the honest fallback is one cheap zone per tester — which keeps every property except the "one domain forever" economics.

Independently, and regardless: rename the cookie to __Host-hub_session. Verified on the live production response that all three prefix preconditions already hold (Secure, Path=/, no Domain), so it genuinely is a one-line change — with one caveat worth writing into the ticket: a browser rejects a __Host- cookie that lacks Secure, and isSecure is conditional, so any plain-HTTP browser access to the hub would stop working. Non-browser access uses Basic auth and is unaffected. Filed as R-136; not implemented here.

---

5. Question D — what breaks with many customers in one zone

What I checked, including what came back clean:

Surface	Checked	Result
Hub uniqueness on domain	store.go:114, configs.go:644	No constraint — duplicate domains accepted silently (R-133)
App subdomain collisions	catalog Host(${SUBDOMAIN}.${DOMAIN})	Clean if each tester has their own label — poll.t1.z vs poll.t2.z
Controller hostname	infra.go:214, web/server.go:571	Clean with nesting, fatal with flat naming — every box wants felhom.<domain>
SMB / NetBIOS names	controller/internal/infra/samba.go:63-65	Clean — workgroup = WORKGROUP fixed, NetBIOS from settings, not the domain. LAN-scoped anyway
storage.cfg / PVE storage names	agent internal/storage/	Clean — no domain-derived names found
Host identity	hub log sess-g-e687c3	Clean — <customer_id>-<random>; the agent never reads customer.domain except in lanresolver
Tunnel naming	dashboard-only, token is the whole config	Clean — tunnels are independent objects; no Felhom-side naming
LE certificate rate limits	—	Not a factor while the edge terminates TLS; becomes one only in the grey-cloud/DNS-01 topology
LAN split-horizon DNS	agent internal/lanresolver/lanresolver.go:6-13	Scoped correctly with nesting (local=/t1.felhomcust.hu/); would hijack the entire zone on that LAN if a customer's domain were the bare zone — another reason flat naming is wrong
Cloudflare geo-WAF rules	controller/internal/cloudflare/{waf,geosync}.go	BROKEN — four distinct cross-tenant faults (R-137)

5.1 The geo-WAF collision — the one real breakage

The rules are written at zone scope with non-namespaced identities:

• waf.go:18 — globalRuleDesc = "[felhom-geo] Global" — one literal description for the whole zone.
• waf.go:21 — appRuleDescPrefix = "[felhom-geo] app:" + the app name, with no customer in the key.
• waf.go:241 — BuildGlobalExpression returns (not ip.src.country in {...}) plus http.host ne exclusions only. There is no positive hostname scoping: the rule matches every hostname in the zone.
• geosync.go:320 — applyDiff deletes every existing [felhom-geo] rule not in this box's desired set.

With two customers in one zone and geo-restriction enabled by either:

1. They overwrite each other forever. Both want a rule described [felhom-geo] Global with different expressions → each sync sees "expression changed" → UpdateRule → flip-flop on every tick.
2. One customer's country policy applies to everyone in the zone, because the expression is not hostname-scoped.
3. Per-app rules collide by name — two testers running rallly both produce [felhom-geo] app:rallly.
4. Disabling the feature for one customer wipes them all — deleteAllRules (geosync.go:167), and the hub's operator "unblock" (hub/internal/cloudflare/unblock.go:22 RemoveGeoRules) deletes all [felhom-geo] rules in the resolved zone.

Mitigation for tester #1 (no code): leave geo-restriction off for every shared-zone customer. Fix (code, R-137): namespace the descriptions by customer_id and add a positive http.host ends_with "<customer domain>" term to both expressions. That is ~4 functions across waf.go/geosync.go plus the hub's RemoveGeoRules — a two-repo change, i.e. exactly the class that dr-recipe-three-producers-hub-allowlist warns about. Small-to-medium, not trivial.

5.2 The shared-zone credential problem

If a shared-zone customer is ever given a cf_api_token (for DNS-01 or geo), that token is Zone:DNS:Edit for the whole shared zone, written to a 0600 .env on a box in a stranger's home (controller/internal/infra/infra.go:123). One compromised tester box could repoint every other tester's DNS. Today each box holds a token only for a zone the operator owns and no one shares, so this is new exposure created by the shared-zone plan. Keep cf_api_token empty for shared-zone customers — which §2.4 shows is supported (HTTP-01). Recorded as part of R-138.

---

6. The operator's step list for tester #1

Ordered, with the prerequisites that bite if taken out of order.

1. Choose and register the customer domain. One registrable domain for all customers, e.g. felhomcust.hu. Not a subdomain of felhom.eu — §4.4.
2. Add the zone to Cloudflare (same account) and point the registrar's nameservers at it.
3. Verify ACM / Total TLS on that zone and enable it. §3.4 — do this before promising a tester a date; without it every hostname the tester touches fails TLS outright. If ACM is not viable, fall back to one zone per tester and stop here.
4. Create the tunnel felhom-t1 in Zero Trust → Networks → Tunnels. Keep the token; it is cf_tunnel_token.
5. Add the public hostnames on that tunnel: felhom.t1.felhomcust.hu plus one per app the tester will run — or a single proxied wildcard *.t1.felhomcust.hu → <tunnel-id>.cfargotunnel.com.
6. Create the customer in the hub — customer_id t1, domain t1.felhomcust.hu, and email = the tester's own working mailbox.

   R-119 prerequisite — this is the step that strands a tester. The dashboard claim code is generated hub-side, bcrypt-hashed, and emailed only; there is no operator-side route to the plaintext. It is sent when the customer record is created and again on POST /configs/<id>/claim-resend. The tester's mailbox must be on the record before their box boots, or the box installs perfectly and nobody can claim it. Confirmed live in this morning's tester-gate run, where the operator had to relay the code by hand.

7. Paste cf_tunnel_token into the customer's Edit tab. Leave cf_api_token empty (§2.4, §5.2).
8. Do not enable geo-restriction for this customer (§5.1).
9. Boot the box from the v1.25.0 generic ISO. It self-registers as an unclaimed appliance; bind it to t1 on the hub's Hosts page; the credentials are delivered once and day-0 completes unattended.
10. The tester claims the dashboard with the emailed code and sets their own password.
11. Sanity-check TLS first, before the tester does: open https://felhom.t1.felhomcust.hu. If it fails with a handshake error rather than a Felhom page, step 3 did not take.

---

7. R-n rows opened

Registered in documentation/backlog/OPEN-ITEMS.md; none implemented.

ID	What	Size
R-133	Hub enforces uniqueness on customer_id only — two customers can be given the same domain with no complaint	XS
R-134	Zone-resolution depth asymmetry: controller strips labels progressively, hub strips exactly one (unblock.go:136)	XS
R-135	validateCSRF returns true when no session cookie is present — with browser-cached Basic auth this is cross-origin CSRF on every mutating hub route	S, security
R-136	Rename hub_session → __Host-hub_session (all preconditions verified met on the production path)	XS, one line
R-137	Cloudflare geo-WAF rules are zone-scoped and non-namespaced — four cross-tenant faults; blocks geo-restriction for any shared zone	M, two-repo
R-138	A shared-zone cf_api_token is a zone-wide DNS-write capability sitting on a customer's box — policy + a guard	S

---

8. What could not be established read-only

• Whether Cloudflare ACM / Total TLS is available or enabled on this account. This is the single decision-critical unknown (§3.4). It needs the Cloudflare dashboard or an API token. The only Cloudflare tokens in reach are the Zone:DNS:Edit tokens in /opt/docker/stacks/traefik/.env on the demo boxes — those can WRITE, so per the fence I did not use them. The hub's own namespace holds no Cloudflare credential at all (checked: 14 secrets, none Cloudflare-related). Operator action: read it off the dashboard.
• The existing tunnels' public-hostname route tables — same reason. So step 5 of §3.5 names the shape but not the exact origin URL the demo tunnels use; copy it from an existing tunnel.
• Whether Cloudflare passes HTTP-01 /.well-known/acme-challenge/ through a proxied hostname to the tunnel origin. Relevant only if cf_api_token is left empty, which §3.5 step 7 recommends. Would need a live issuance attempt on a real hostname — i.e. tester #1's first boot. If it fails, the fallback is to set cf_api_token and accept §5.2's exposure, or rely on the edge cert alone.
• Browser Basic-auth resend behaviour underlying R-135 is stated from the specification, not measured here; a browser is needed and claude-in-chrome is unavailable on DooPlex.

9. What was not done

No customer, DNS record, tunnel, route or code change was created. No demo box, drill-r50, guest 9201 or Peti's cluster was touched — the only writes anywhere were two hub login sessions (in-memory, 7-day expiry, tokens shredded) and this document plus the six register rows. curl -w '%{redirect_url}' was not used (R-132).