I have set up lighttpd as a reverse proxy to access each service's WebUI via a own subdomain inside the home network. (pihole.dietpi.home for Pi-hole).
Pi-hole's webserver is configured to run on 127.0.0.1:8080.
SSL configuration and certificate handling is done by lighttpd.
This basically works as desired, but
with webserver.tls.rev_proxy enabled, the icon on the hamburger menu shows the connention as end-to-end-encrypted.
But the symbol at the Currently active sessions table shows that as NOT end-to-end-encrypted even if the client connects via https.
in both the hamburger menu and the Currently active sessions table the Client IP shows up as 127.0.0.1 wich in first place isn't incorrect.
But is there a way to pass the real client's IP there to better identify the client?
I tried adding Forwarded and some headers to the lighttpd config, but nothing worked.
There is way to actually detect if the reverse proxy is going HTTPS or not. One could even argue that the tooltip is incorrect: There is end-to-end security at this point as your reverse proxy is acting as a man-in-the-middle by construction.
So far, the mentioned setting does nothing more than changing this one icon + tooltip but my argument is that this is actually wrong so, instead of what you hoped for - extending the scope of the setting - I'd actually go the other way and remove this ill-fated config option altogether. There is just no way the application can reliably know if the entire path between the client and server is encrypted in such a configuration. The sessions table is correct at pointing this out.
I'm thorn about this. Currently, we take the raw connection peer which is 127.0.0.1 in your particular configuration and don't bother at all with evaluating headers. Note that the IP address is part of the security here, it is not possible to steal the session and reuse it from another origin. If we'd allow rewriting the claimed IP via some arbitrary header, it'd actually lessen the security in most cases[1].
yes, I know, it has zero security benefit if everything comes from 127.0.0.1 in you case but it does have an effect for "normal" deployments. ↩︎
I aggree with your argumentation about the webserver.tls.rev_proxy option.
Maybe it would be possible to add some short hint (something like "via Proxy" to the IP address at the hamburger menu as well as also show the given Client IP from Forwarded for header in the sessions table if there is any sent instead of rewriting the 127.0.0.1.
Removing the option could be seen as a bug fix but the second part is definitely a feature request. Everything is working as it should, it's "just" cosmetics in the reverse-proxy setup which is non-standard configuration.
We'd need to implement header handling (easy) and proper parsing (easy enough, just use the left-most full IP address) and then modify the sessions table to be able to store two IP addresses. Not overly complex but it still needs some tie to do it and then proper testing.
How'd you suggest detecting the "via proxy" case? By the existence of some X-Forwarded-For header?
Having thought about this, I actually think we should remove the option but not add the header parsing. My comment above was not accurate anyway:
We removed this some time ago as a few clients used IPv4 and IPv6 alternating which made sessions pinned to a specific IP actually adverse. Having this in mind, I don't see any gain (else than showing in the table) but it adds quite a bit of code.
Quering this board for reverse proxy threads, there are some.
In the current v5 release, neither the client IP nor the status of end-to-end encryption is displayed in the dashboard.
With v6, the log-in page already recommends the use of an https connection.
Perhaps those proxy users will then (after the update to v6) also be irritated by the fact that the https connection is displayed as "NOT end-to-end encrypted" and only 127.0.0.1 is displayed as the client IP and may ask questions about this.
But maybe it won't bother them, I don't know.
Possibly others will then ask for that feature...
Once the option is removed, it will cause even more work to re-implement and extend it later due to a feature request, right?!
pihole checkout web tweak/proxy
pihole checkout ftl tweak/proxy
If there is an X-Forwarded-For header, we expect this to be shown as IP address. To signal that something is different, we show the IP address in italics and the "real" remote address in a hover-over tooltip.
It is a bit more tricky here. We don't use a API call here but instead use a LUA variable during rendering mg.request_info.remote_addr. We need to iterate through the array mg.request_info.http_headers and check for X-Forwarded-For. I pushed this to the branch just now.
So it is available on every page. There are other metrics as well such as the rendering time of the page. This has been requested through the discussion about browsers happily alternating between IPv4 and IPv6. It isn't important at all, just there for the curious.
