Hi Wade, Am 03.09.24 um 19:22 schrieb Cline, Wade:
As I recall, openconnect via NM uses a two-step process in order to establish the VPN connection and what you're seeing is the second step of that process. The first step runs as a regular user and does the authentication while the second step runs as root and actually establishes the VPN connection. Part of the first step is verifying the server's certificate; the verified certificate is then passed on to the second step explicitly via --servercert. Though this can result in a rather unfortunate log entry (3rd line):NetworkManager[3427]: Connected to REDACTED NetworkManager[3427]: SSL negotiation with REDACTED NetworkManager[3427]: Server certificate verify failed: signer not found NetworkManager[3427]: Connected to HTTPS on REDACTED with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM) When I tested it, server cert vertification was working correctly when I specified an invalid fingerprint (see the --authenticate option for details).
Looks like you are completely right. The behavior of NM comes a bit unexpected, but there is nothing insecure with it. Thanks everyone for clarifying things. One _might_ think about renaming --cafile to something like --add-ca-file to avoid a misunderstanding like ours in the first place, but you still you have to read the docs if you want to pin the server cert or similar. So not sure this would help at all. Luckily, there are no current attacks I know of trying to mimic our VPN gateway, so no immediate danger from that direction. Regards, 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
