I’m sorry to say this, but the answer scares me a bit.
I’d rather pay the price for redundant security than disable a global security feature (requiring TLS for the browser) because ONE software component doesn’t work with it.
To ensure my comment is properly understood, I would like to elaborate on my concerns:
Yes, sniffing normally requires privileges so high that other attack vectors can also be used.
However, there are countless examples of special privilege escalations through security vulnerabilities in system components. For example, with a bug in the network stack or another component, sniffing does not require REGULARLY acquired higher privileges. Security considerations should NEVER only extend to the NORMAL CASE, but ALWAYS also to the SPECIAL CASE. These are the cases you need to plan for; everything else is just following the usual procedures. In the event of an attack, you want to leave as few options open to the attacker as possible. Ideally, the attacker should be (effectively) no further ahead than before.
My reverse proxies “route” from external TLS (signed) to internal TLS (unsigned), even though, or precisely because, this happens internally within the network, and therefore sniffing would be possible at some point (some adopted component).
A localhost connection within a SINGLE server is, of course, common practice, but a NetServer 8 is NOT a SINGLE server; it’s a container orchestrator, and thus an ENTIRE network in ONE machine. And I think that’s how they should be viewed and designed to be secure accordingly. Please tell me you don’t think this is completely absurd.
From an operational (and system design) perspective, a SSH tunnel (and Traefik TLS offloading) is 100% safe.
- Unless there’s a bug in the kernel code.
- Unless there’s a bug in the user-space code, like the Browser, or OpenSSL libraries.
- Unless etc…
For all those doubts, regular system updates are the best thing we can do.
Dear Davide, thank you very much for your answer.
It’s possible that I’m not able to express my thoughts properly. It’s possible that we’re talking past each other. It’s possible that my way of asking questions is too confrontational to expect answers to some aspects. If the latter is the case, I apologize. I’d rather not reveal myself on this point, but I’d just like to assure you that I’m always only interested in content, and personal attacks are neither the means nor the goal (even though that’s unfortunately often perceived that way).
So let me put my question differently:
As a reverse proxy, the Trafik is the interface between the user’s browser and the service in the Nethserver container. The services in the container don’t use TLS themselves (it doesn’t matter), but the Trafik offers it to external browsers. The connection between the “Nethserver” and the user’s browser is encrypted. Everything as it should be.
This is essentially how it works with the “Cluster Admin” as well. The maintenance technician’s browser receives a TLS connection from the Traefik, which is then forwarded to the container (in this case, “localhost:9311”). Here, too, the connection between the technician’s browser and the Nethserver 8 is encrypted. Everything as it should be (Let’s leave security aspects in the Orchestrator aside for now.)
The latter only works if the Traefik is accessed via the Nethserver’s local IP. However, if the Traefik is accessed from an SSH tunnel (whose endpoint is in the Nethserver 8 host itself), it doesn’t work completely. The login page appears, but all other pages do not.
Why this distinction? Is this a bug that still needs to be fixed or a design decision? Why can I reach 127.0.0.1:9311 from the tunnel, but not 127.0.0.1:443/cluster-admin (only Login page)?
I realize there are more urgent issues that need to be resolved, but I’d like to understand what they are and whether it makes sense to wait.
Best regards, Yummiweb
They both work after the bug fix. For example, about port 443:
ssh -L 8443:127.0.0.1:443 ns8.test
Specifically, a SSH tunnel to port 443 has always been possible. Now, if you restrict access to /cluster-admin by IP and you still want to access it by SSH tunnel, do not forget to list 127.0.0.1 as well.
About port 9311:
ssh -L 8311:127.0.0.1:9311 ns8.test
Tunnel to port :9311 was not possible before the bug fix for the websocket protocol mismatch. Now it’s fixed.
In both cases the client encryption terminates on the ns8 node and a clear-text proxied* connection is reopened on ns8 from 127.0.0.1:{some OS assigned port} to 127.0.0.1:9311 (ns8 itself), because api-server does not know what TLS is. For this reason double-encryption is useless in any case.
*) the proxy in this case can be Sshd or Traefik
1 Like
Thank you for your persistent clarification! When searching for a bug, it helps immensely with motivation to be as certain as possible that it MUST work.
So I tested it again in a more structured way and discovered:
The problem occurs ONLY in the (MacOS) Safari browser (16.6.1), even though “normal” access to “cluster-admin” works and all caches for 127.0.0.1 are empty. I even created a new user and tried it under that, but it doesn’t work there either.
It works with Safari 17.6 (although it uses a different client).
Tested with Nethserver 8 Core 3.6.2, 3.6.4, and 3.7.1 (unfortunately, 3.7.0 is no longer available for testing).
I just can’t think of a reason why Safari can open the “Cluster Admin” directly but not the tunneled “Cluster Admin”? Especially since I access various configuration pages this way (via a tunnel) (Proxmox VE, Proxmox PMG, other web configurations) and have always done so via Safari.
I’ve now found the solution (using the “Cluster Admin” tunnel with other browsers), but perhaps this observation will help elsewhere…
Regards, Yummiweb
1 Like