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@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: pa...@hrz.uni-marburg.de > D-35032 Marburg > _______________________________________________ > openconnect-devel mailing list > openconnect-devel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/openconnect-devel _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
