--cafile enabling system-trust nevertheless?

[Daniel Lenski]

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).
- 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`.

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.

> (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


Daniel