--cafile enabling system-trust nevertheless?

[Cline, Wade]

On Fri, Aug 30, 2024 at 07:14:07PM +0200, Martin Pauly wrote:
> 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

Hi Martin,

Isn't '--cafile' for *additional* CAs and hence the above command includes
both the system certs and the T-Telesec cert (possibly redundantly)?
Wouldn't you want to explicitly specify the T-Telesec cert with '--cafile'
and '--no-system-trust' for the above test?

You might also want to look at 'openssl s_client -showcerts -connect
vpn.uni-marburg.de:443' in order to analyze the full certificate chain.

Regards,
Wade

> 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



> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel