From b59b5bf6bee03e7e61bb6abccd25b1ed8100f051 Mon Sep 17 00:00:00 2001 From: jwed Date: Fri, 21 Aug 2026 13:20:06 -0400 Subject: [PATCH] Spec: proxy_untrusted is not a sufficient outage alarm MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Found while implementing the resolver. The spec claimed the difference between "no client matched this IP" and "this IP is the proxy" made a TrustProxies misconfiguration one glance to diagnose. That holds only for the case where the forwarded header arrives and TrustProxies fails to apply it. If Traefik is misconfigured such that no X-Forwarded-For is sent at all, the resolver sees a plain unmatched IP and reports no_client — which reads to the person in front of it as "your device is not on the network", and to an operator as nothing at all. The alarm is silent in precisely one of the two ways the thing it guards can break. Recorded rather than patched, because the fix belongs to Plan 2's health line: it should show the resolved client IP and say what it is, instead of reporting a reason code. And the hardware validation step now has to confirm the true client IP actually arrives — confirming the alarm is quiet is not evidence, since a quiet alarm is what this blind spot produces. --- ...2026-08-21-byod-wifi-portal-hardening-design.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/docs/superpowers/specs/2026-08-21-byod-wifi-portal-hardening-design.md b/docs/superpowers/specs/2026-08-21-byod-wifi-portal-hardening-design.md index 759bd18..f29ab6b 100644 --- a/docs/superpowers/specs/2026-08-21-byod-wifi-portal-hardening-design.md +++ b/docs/superpowers/specs/2026-08-21-byod-wifi-portal-hardening-design.md @@ -137,6 +137,20 @@ is the proxy", and the second is surfaced as a health line on the Wi-Fi Devices page. The failure becomes one glance to diagnose instead of a mystery. This is also the single most important thing to verify against the live controller. +**Known blind spot in that detection** (found during implementation, 2026-08-21). +`proxy_untrusted` is inferred from `X-Forwarded-For` being present while +`$request->ip()` still equals the raw `REMOTE_ADDR` — that is, the header arrived +but `TrustProxies` did not apply it. It therefore does NOT catch a Traefik +misconfiguration that sends no forwarded header at all: that degrades to +`no_client`, which reads as "your device is not on the network" rather than "this +is broken, tell IT". + +So `proxy_untrusted` is a useful signal but **not a sufficient outage alarm**. The +hardware validation step must confirm the true client IP actually arrives, rather +than confirming that the misconfiguration alarm is quiet — a quiet alarm is +exactly what the blind spot produces. Plan 2's health line should read the +resolved IP itself and say what it is, not merely report a reason code. + ### MAC randomization Normally stable per SSID, so it does not break the design. When it does rotate,