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 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
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
