On Fri, 2024-09-06 at 22:14 -0700, Daniel Lenski wrote: > On Mon, Sep 2, 2024 at 4:56 AM Martin Pauly <pa...@hrz.uni-marburg.de> wrote: > > > > Am 01.09.24 um 06:32 schrieb Daniel Lenski: > > > > Actually, the original question came from the GUI side, i.e. Network > > Manager. > > A colleague of mine recently stumbled on our outdated documentation > > recommending to set CA Certificate to the old T-Telesec cert. > > He figured out he could connect to my current server (presenting the new > > USERTrust cert) > > no matter what CA element he added of left blank. > > When testing, I naïvely assumed the "CA Certificate" would directly > > translate to --cafile. > > Add the old manpage, and you have my perfect misinterpretation. > > > > But a closer look reveals different details yet again, identical on both > > the old Ubuntu and a current Debian. > > No matter what I specify in "CA Certificate", ps always shows this Command > > line being run in reality: > > nm-open+ 39622 0.1 0.0 62992 12672 ? S 11:17 0:00 > > /usr/sbin/openconnect --servercert > > pin-sha256:BjvO2hCuK4pVXupG9fmwOAbdsaTc/LORPdn6Al2LRD0= --syslog > > --cookie-on-stdin --script > > /usr/lib/NetworkManager/nm-openconnect-service-openconnect-helper > > --interface vpn0 137.248.1.225:443/+webvpn+/index.html > > > > The pin-sha256:BjvO2hCuK4pVXupG9fmwOAbdsaTc/LORPdn6Al2LRD0= > > matches the current USERTrust cert > > [[[ Just before I hit send, seeing that Wade Cline has already replied > and explained most of this 👇, but perhaps this additional detail is > useful. ]]] > > OpenConnect is explicitly designed to separate the authentication and > tunnel/data "phases" of a VPN connection, so that they can run in > separate processes. > > - What you're seeing here is the tunnel/data phase, running in the > `openconnect` process (as a privileged user).
No, NetworkManager runs openconnect as an *unprivileged* user. Not actually "nobody" but its own "NM-openconnect" version of nobody. All it can do is open the one /dev/net/tun device which was created for it by NetworkManager, and shovel packets back and forth. And send the IP configuration back to NetworkManager via D-Bus to be set up. Running unprivileged in the tunnel phase is a key part of the openconnect security model (and it's different to the Cisco crap, which runs as root for a lot of things where it really shouldn't). If you run openconnect from the *command* line, then yes it'll need to invoke its vpnc-script with CAP_NET_ADMIN in order to configure the networking. And CAP_SYS_ADMIN to let it write /etc/resolv.conf. But in that model you can still do the *authentication* as your normal user, as shown at https://www.infradead.org/openconnect/nonroot.html (And even then, strictly openconnect itself doesn't need privs; I've never experimented much with 'openconnect -s "sudo vpnc-script", and I'm not entirely sure there's much point without a lot of focus on hardening vpnc-script itself to be a safe entry point.) > - The authentication phase has *already run* as part of the GUI > process (as an unprivileged user). > > What happens in the authentication phase is that you fill out the > authentication forms and communicate with the server, which sends an > authentication token (it's simply an HTTP cookie in the case of the > AnyConnect protocol). NM records the fingerprint of the server's TLS > certificate during the authentication phase, as well as the > authentication token/cookie. > > In order to establish the tunnel/data phase connection, NetworkManager > starts a new (privileged) `openconnect` process, feeding it the > authentication token via `--cookie-on-stdin`, and requiring the server > certificate to exactly match the one seen during the authentication > phase via `--servercert pin-sha256:$HASH` Even when round robin DNS is being used with a pool of servers, the cookie tends to be only valid on the one server that gave it out, so it's important to connect back to that *same* server. Which is why we pass not just the hostname but also the specific IP address to the openconnect that's used for the tunnel phase. > Most of the documentation on the 2-phase authentication lives in the > code and devs' heads, but there are some references in the manual > (https://www.infradead.org/openconnect/manual.html#:~:text=The%20connection%20happens,tcp.html. > and https://www.infradead.org/openconnect/manual.html#opt-authenticate) > and in a 2020 presentation that I gave > (https://www.dropbox.com/scl/fi/2ideixgr6sa7jcw49glbu/How-VPNs-Work-Daniel-Lenski-at-DAMA-PDX-September-2020.pdf). > > > so Network Manager always seems to call openconnect > > as if I had enabled --no-system-trust, but trusted the current USERtrust > > cert > > explicitly -- is this correct? > > > > If so, is this intended behavior? > > As described above, the actual certificate *validation* happens during > the authentication phase, and you're only seeing the *tunnel* phase > here. So this *is* the intended behavior, but an incomplete picture of > what has actually happened in terms of cert validation. > > > And: Is there a NM/GUI setting equivalent to --no-system-trust? > > My knowledge of the NM GUI is both incomplete and out-of-date, but not > as far as I know. Indeed, but it would be trivial to add. > > (Really sorry to bother, we've turned to a "Once bitten, twice shy" mindset > > after we learned that leaving a CA setting blank has proved disastrous > > in the context of WiFi supplicants. With openconnect, we're obviously > > apart from that kind of problems by a long shot.) > > Ooh, interesting. Reading between the lines a bit here… "leaving a CA > setting blank" in WiFi enterprise authentication (802.1x) resulted in > "don't validate the RADIUS server's certificate at all." So your > clients then connected to forged/spoofed APs+RADIUS servers!? > > You'll probably be reassured to know that openconnect (the CLI > application) has not had an option to disable certificate validation > altogether in many year 😅. > https://gitlab.com/openconnect/openconnect/commit/6c95e85f154f2ee24b8914ab6c0ffe555152ca7f Right. I figured even providing that *option* to users was a bad idea. Saw one too many "helpful" pastebin/stackexchange/whatever snippets with the --no-cert-check option, threw my toys out of the pram a little bit and ripped it out :)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
