Attention is currently required from: plaisthos, selvanair. Bluca has posted comments on this change by Bluca. ( http://gerrit.openvpn.net/c/openvpn/+/1622?usp=email )
Change subject: Add new helpers to handle key exchange (S_SENT_KEY/S_START) with large passwords ...................................................................... Patch Set 2: (2 comments) Patchset: PS1: > But I get the feeling that you are not really interested in any solution that > would actually improve on the OpenVPN protocol to implement longer > username/password if it is not compatible with the approach that Microsoft > has decided to take. Of course what I am after is making my use case work, otherwise what would be the point? I don't think there's anything wrong with wanting to fix things that don't work, that's how open source contributions happen after all, everyone has their own itches to scratch, and mine is being able to ditch all proprietary software from my machine and still be able to do my job. It doesn't feel like it's a bad goal to have, no? So if you have specific suggestions that can improve the situation in _both_ cases, I'd be happy to work on implementing them. PS1: > You might not care about compatibility, interoperability and behaviour of > modern clients with older servers and vice versa but we care and we have take > that into account. This is not true, and I must say being on the receiving end of such jibes is really not motivating, as I've been testing these changes in various combinations as explained in the commit message exactly because I don't want to break anything. But one thing is breaking backward compatibility, and something entirely different is when something _never worked_ in the first place. This is what happens when trying to use a long password with various combinations of existing client/server pairings. Pre-a7f80d402f client to pre-a7f80d402f server: 2026-04-08 00:53:44 us=768916 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940 2026-04-08 00:53:44 us=769011 TCP connection established with [AF_INET]127.0.0.1:11940 2026-04-08 00:53:44 us=769020 TCPv4_CLIENT link local: (not bound) 2026-04-08 00:53:44 us=769026 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940 2026-04-08 00:53:44 us=769450 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid=34dfa3d7 a78d4716 2026-04-08 00:53:44 us=769480 TLS Error: Key Method #2 write failed 2026-04-08 00:53:44 us=769486 TLS Error: TLS handshake failed 2026-04-08 00:53:44 us=769527 Fatal TLS error (check_tls_errors_co), restarting 2026-04-08 00:53:44 us=769541 TCP/UDP: Closing socket 2026-04-08 00:53:44 us=769569 SIGUSR1[soft,tls-error] received, process restarting 2026-04-08 00:53:44 us=769582 Restart pause, 1 second(s) 2.7 client (without this patch) to pre-a7f80d402f server: 2026-04-08 01:08:17 us=72026 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940 2026-04-08 01:08:17 us=72132 TCP connection established with [AF_INET]127.0.0.1:11940 2026-04-08 01:08:17 us=72141 TCPv4_CLIENT link local: (not bound) 2026-04-08 01:08:17 us=72147 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940 2026-04-08 01:08:17 us=72596 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid=dd20ab34 e3af8d3c 2026-04-08 01:08:17 us=72627 TLS Error: Key Method #2 write failed 2026-04-08 01:08:17 us=72636 TLS Error: TLS handshake failed 2026-04-08 01:08:17 us=72702 Fatal TLS error (check_tls_errors_co), restarting 2026-04-08 01:08:17 us=72721 TCP/UDP: Closing socket 2026-04-08 01:08:17 us=72753 SIGUSR1[soft,tls-error] received, process restarting 2026-04-08 01:08:17 us=72766 Restart pause, 2 second(s) 2.7 client (without this patch) to 2.7 server (without this patch): 2026-04-08 01:10:10 us=299468 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940 2026-04-08 01:10:10 us=299563 TCP connection established with [AF_INET]127.0.0.1:11940 2026-04-08 01:10:10 us=299574 TCPv4_CLIENT link local: (not bound) 2026-04-08 01:10:10 us=299581 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940 2026-04-08 01:10:10 us=299899 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid=ef841a67 6d757318 2026-04-08 01:10:10 us=299912 TLS Error: Key Method #2 write failed 2026-04-08 01:10:10 us=299917 TLS Error: TLS handshake failed 2026-04-08 01:10:10 us=299967 Fatal TLS error (check_tls_errors_co), restarting 2026-04-08 01:10:10 us=299989 TCP/UDP: Closing socket 2026-04-08 01:10:10 us=300016 SIGUSR1[soft,tls-error] received, process restarting 2026-04-08 01:10:10 us=300026 Restart pause, 2 second(s) pre-a7f80d402f client to 2.7 server (without this patch): 2026-04-08 01:11:56 us=44683 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940 2026-04-08 01:11:56 us=44820 TCP connection established with [AF_INET]127.0.0.1:11940 2026-04-08 01:11:56 us=44827 TCPv4_CLIENT link local: (not bound) 2026-04-08 01:11:56 us=44831 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940 2026-04-08 01:11:56 us=45442 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid=9f2bc992 ef68a461 2026-04-08 01:11:56 us=45469 TLS Error: Key Method #2 write failed 2026-04-08 01:11:56 us=45475 TLS Error: TLS handshake failed 2026-04-08 01:11:56 us=45522 Fatal TLS error (check_tls_errors_co), restarting 2026-04-08 01:11:56 us=45537 TCP/UDP: Closing socket 2026-04-08 01:11:56 us=45572 SIGUSR1[soft,tls-error] received, process restarting 2026-04-08 01:11:56 us=45582 Restart pause, 1 second(s) Basically the only difference is that the new version waits 2s instead of 1s. The message is exactly the same, an unspecified "key method" failure, that doesn't really say the password is too long, and is entirely unhelpful to a casual user. The error reporting from a7f80d402f doesn't trigger in any combination. Now here's how it looks with this patch, when connecting to a 2.7 server before this patch: 2026-04-08 01:34:55 us=526614 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940 2026-04-08 01:34:55 us=526683 TCP connection established with [AF_INET]127.0.0.1:11940 2026-04-08 01:34:55 us=526690 TCPv4_CLIENT link local: (not bound) 2026-04-08 01:34:55 us=526694 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940 2026-04-08 01:34:55 us=527014 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid=b3756543 a0f9575c 2026-04-08 01:34:55 us=527030 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2026-04-08 01:34:55 us=527737 VERIFY OK: depth=1, CN=Test CA 2026-04-08 01:34:55 us=527836 VERIFY OK: depth=0, CN=server 2026-04-08 01:34:55 us=568575 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 256 bits ECprime256v1, signature: ecdsa-with-SHA256, peer signing digest/type: ecdsa_secp256r1_sha256 ECDSA, key agreement: X25519MLKEM768 2026-04-08 01:34:55 us=568624 [server] Peer Connection Initiated with [AF_INET]127.0.0.1:11940 2026-04-08 01:34:55 us=568639 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1 2026-04-08 01:34:55 us=568717 TLS: tls_multi_process: initial untrusted session promoted to trusted 2026-04-08 01:34:55 us=569034 AUTH: Received control message: AUTH_FAILED,Username or password is too long. Maximum length is 128 bytes 2026-04-08 01:34:55 us=569150 TCP/UDP: Closing socket 2026-04-08 01:34:55 us=569194 SIGTERM[soft,auth-failure] received, process exiting IE: the new error path reporting from a7f80d402f actually fires up, and reports a useful and actionable message to the user. With a pre-a7f80d402f server there was no helpful message with a patched client, so I've now added it. So not only this patch doesn't break compatibility or make the UX worse, it actually improves it in the error case. -- To view, visit http://gerrit.openvpn.net/c/openvpn/+/1622?usp=email To unsubscribe, or for help writing mail filters, visit http://gerrit.openvpn.net/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: openvpn Gerrit-Branch: master Gerrit-Change-Id: I055c64ca8b23066e70eea7d7deddfb14f5354c5f Gerrit-Change-Number: 1622 Gerrit-PatchSet: 2 Gerrit-Owner: Bluca <[email protected]> Gerrit-Reviewer: plaisthos <[email protected]> Gerrit-Reviewer: selvanair <[email protected]> Gerrit-CC: openvpn-devel <[email protected]> Gerrit-Attention: plaisthos <[email protected]> Gerrit-Attention: selvanair <[email protected]> Gerrit-Comment-Date: Wed, 08 Apr 2026 00:54:40 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: plaisthos <[email protected]> Comment-In-Reply-To: Bluca <[email protected]>
_______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
