--cafile enabling system-trust nevertheless?

[Martin Pauly]

Hi all,

we have encountered what we think might be a sloppy check of the server cert by the openconnect client.
AFAIU, --cafile allows the user to pin the CA that has signed off the server cert to a certain root cert.
This is supposed to enable a much stricter server identity check than one gets with the
default behavior of trusting any known system cert (e.g. any of the root certs in /etc/ssl/certs).

A while ago, we changed our CA from T-Telesec to USERTrust,
so the CA file to check against should be
/etc/ssl/certs/USERTrust_RSA_Certification_Authority.pem on current Debian/Ubuntu, with SHA-256 Fingerprint
E7:93:C9:B0:2F:D8:AA:13:E2:1C:31:22:8A:CC:B0:81:19:64:3B:74:9C:89:89:64:B1:74:6D:46:C3:D4:CB:D2

But using the old CA file (or any other one of the system certs) will not cause openconnect to complain:
------------------------------------------------------------ START ----------------------------------------------------------
user at linux> openconnect --authgroup=unimr-vpn-staff-Passwort+2FA -u pauly --cafile=/etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem  vpn.uni-marburg.de
POST https://vpn.uni-marburg.de/
Connected to 137.248.1.225:443
SSL negotiation with vpn.uni-marburg.de
Connected to HTTPS on vpn.uni-marburg.de with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
Got HTTP response: HTTP/1.1 404 Not Found
Unexpected 404 result from server
GET https://vpn.uni-marburg.de/
Verbunden mit 137.248.1.225:443
SSL negotiation with vpn.uni-marburg.de
Connected to HTTPS on vpn.uni-marburg.de with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
Got HTTP response: HTTP/1.0 302 Object Moved
GET https://vpn.uni-marburg.de/+webvpn+/index.html
SSL negotiation with vpn.uni-marburg.de
Connected to HTTPS on vpn.uni-marburg.de with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
Please enter your username and password.
Please enter your username and password.
Password:

------------------------------------------------------------ STOP ----------------------------------------------------------

OTOH, using --no-system-trust without --servercert does elicit a prompt to manually accept the server cert,
as do name/SAN mismatches (and presumably expired or self-signed server certs, not tested yet).
But this is would apply to a different situation. Pinning to root CA + SAN is a highly important
configuration option that can ensure for years your clients only connect to the right thing,
and still you can update your server cert every year or so.

Have we missed something, or is this a security issue?

Cheers, Martin

-- 
   Dr. Martin Pauly     Phone:  +49-6421-28-23527
   HRZ Univ. Marburg    Fax:    +49-6421-28-26994
   Hans-Meerwein-Str.   E-Mail: pauly at HRZ.Uni-Marburg.DE
   D-35032 Marburg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20240830/a6455406/attachment.p7s>