jwed/central-unifi
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Spec: proxy_untrusted is not a sufficient outage alarm

Browse Source 
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.
This commit is contained in:
jwed
2026-08-21 13:20:06 -04:00
parent 4322d07b40
commit b59b5bf6be
1 changed files with 14 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/superpowers/specs/2026-08-21-byod-wifi-portal-hardening-design.md
View File

@@ -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 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. 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 ### MAC randomization
Normally stable per SSID, so it does not break the design. When it does rotate, Normally stable per SSID, so it does not break the design. When it does rotate,