--cafile enabling system-trust nevertheless?

[David Woodhouse]

On Fri, 2024-09-06 at 22:14 -0700, Daniel Lenski wrote:
> On Mon, Sep 2, 2024 at 4:56 AM Martin Pauly <pauly at 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 :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20240907/5f2d3436/attachment.p7s>