)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"cafb98103ab7761b04898f30b906b085d73e9ffe","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d49917cc_8d5c2031","updated":"2026-04-07 01:00:30.000000000","message":"\u003e With the last combination, a large password can be used successfully.\nWith either an old server or old client, existing limits apply and\na clear error is shown in case one tries a password longer than the\nexisting limits.\n\nThe clear error message is a quite recent change https://github.com/OpenVPN/openvpn/commit/a7f80d402fb95df3c58a8fc5d12cdb8f39c37d3e\n\nYou get very weird errors and behaviour on OpenVPN versions older than this commit. So only 2.6.13 or newer will actually give a clear error message.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"d47344cd3ebbc31a3e2cc4bc34d03353125c7195","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9ba7f3da_0457b2f0","updated":"2026-04-06 11:50:19.000000000","message":"Here\u0027s an alternative proposal to what was discussed here:\n\nhttps://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/20260315184337.1541272-1-luca.boccassi%40gmail.com/#msg59309369\nhttps://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/20260316224531.315912-1-luca.boccassi%40gmail.com/#msg59309910\n\nThe goal is to allow clients to optionally use longer passwords, without impacting existing users. As far as I can tell, with testing too, this should not impact existing usage.\n\nWith this change and the management interface change that was merged, I am able to use the OpenVPN client to connect to AzureVPN using a JIT-generated use-once authentication token, which is typically ~3k in size.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"8d92bcb209a45678c70671878f35c1553181e786","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"49f357a0_f3d62688","updated":"2026-04-07 00:48:54.000000000","message":"I think this is a very hacky approach to solve this problem. I think we can better than that and design a proper protocol extension that allows larger username and password.\n\nWe would be better to not doctor around the problem of broken framing but rather negotiate allowing record spliting and allow more dynamic frame sizes than the 2048. Then we can also have proper support for longer username and password.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"3b98c9bf5489fa5eb86a3cbcc498c722ac2020ee","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6e70f1de_f80b9722","in_reply_to":"1a0a3cf2_b0d45c35","updated":"2026-04-08 00:54:40.000000000","message":"\u003e 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.\n\nThis is not true, and I must say being on the receiving end of such jibes is really not motivating, as I\u0027ve been testing these changes in various combinations as explained in the commit message exactly because I don\u0027t want to break anything.\n\nBut one thing is breaking backward compatibility, and something entirely different is when something _never worked_ in the first place.\n\nThis is what happens when trying to use a long password with various combinations of existing client/server pairings.\n\nPre-a7f80d402f client to pre-a7f80d402f server:\n\n2026-04-08 00:53:44 us\u003d768916 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940\n2026-04-08 00:53:44 us\u003d769011 TCP connection established with [AF_INET]127.0.0.1:11940\n2026-04-08 00:53:44 us\u003d769020 TCPv4_CLIENT link local: (not bound)\n2026-04-08 00:53:44 us\u003d769026 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940\n2026-04-08 00:53:44 us\u003d769450 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid\u003d34dfa3d7 a78d4716\n2026-04-08 00:53:44 us\u003d769480 TLS Error: Key Method #2 write failed\n2026-04-08 00:53:44 us\u003d769486 TLS Error: TLS handshake failed\n2026-04-08 00:53:44 us\u003d769527 Fatal TLS error (check_tls_errors_co), restarting\n2026-04-08 00:53:44 us\u003d769541 TCP/UDP: Closing socket\n2026-04-08 00:53:44 us\u003d769569 SIGUSR1[soft,tls-error] received, process restarting\n2026-04-08 00:53:44 us\u003d769582 Restart pause, 1 second(s)\n\n2.7 client (without this patch) to pre-a7f80d402f server:\n\n2026-04-08 01:08:17 us\u003d72026 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940\n2026-04-08 01:08:17 us\u003d72132 TCP connection established with [AF_INET]127.0.0.1:11940\n2026-04-08 01:08:17 us\u003d72141 TCPv4_CLIENT link local: (not bound)\n2026-04-08 01:08:17 us\u003d72147 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940\n2026-04-08 01:08:17 us\u003d72596 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid\u003ddd20ab34 e3af8d3c\n2026-04-08 01:08:17 us\u003d72627 TLS Error: Key Method #2 write failed\n2026-04-08 01:08:17 us\u003d72636 TLS Error: TLS handshake failed\n2026-04-08 01:08:17 us\u003d72702 Fatal TLS error (check_tls_errors_co), restarting\n2026-04-08 01:08:17 us\u003d72721 TCP/UDP: Closing socket\n2026-04-08 01:08:17 us\u003d72753 SIGUSR1[soft,tls-error] received, process restarting\n2026-04-08 01:08:17 us\u003d72766 Restart pause, 2 second(s)\n\n2.7 client (without this patch) to 2.7 server (without this patch):\n\n2026-04-08 01:10:10 us\u003d299468 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940\n2026-04-08 01:10:10 us\u003d299563 TCP connection established with [AF_INET]127.0.0.1:11940\n2026-04-08 01:10:10 us\u003d299574 TCPv4_CLIENT link local: (not bound)\n2026-04-08 01:10:10 us\u003d299581 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940\n2026-04-08 01:10:10 us\u003d299899 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid\u003def841a67 6d757318\n2026-04-08 01:10:10 us\u003d299912 TLS Error: Key Method #2 write failed\n2026-04-08 01:10:10 us\u003d299917 TLS Error: TLS handshake failed\n2026-04-08 01:10:10 us\u003d299967 Fatal TLS error (check_tls_errors_co), restarting\n2026-04-08 01:10:10 us\u003d299989 TCP/UDP: Closing socket\n2026-04-08 01:10:10 us\u003d300016 SIGUSR1[soft,tls-error] received, process restarting\n2026-04-08 01:10:10 us\u003d300026 Restart pause, 2 second(s)\n\npre-a7f80d402f client to 2.7 server (without this patch):\n\n2026-04-08 01:11:56 us\u003d44683 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940\n2026-04-08 01:11:56 us\u003d44820 TCP connection established with [AF_INET]127.0.0.1:11940\n2026-04-08 01:11:56 us\u003d44827 TCPv4_CLIENT link local: (not bound)\n2026-04-08 01:11:56 us\u003d44831 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940\n2026-04-08 01:11:56 us\u003d45442 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid\u003d9f2bc992 ef68a461\n2026-04-08 01:11:56 us\u003d45469 TLS Error: Key Method #2 write failed\n2026-04-08 01:11:56 us\u003d45475 TLS Error: TLS handshake failed\n2026-04-08 01:11:56 us\u003d45522 Fatal TLS error (check_tls_errors_co), restarting\n2026-04-08 01:11:56 us\u003d45537 TCP/UDP: Closing socket\n2026-04-08 01:11:56 us\u003d45572 SIGUSR1[soft,tls-error] received, process restarting\n2026-04-08 01:11:56 us\u003d45582 Restart pause, 1 second(s)\n\n\nBasically 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\u0027t really say the password is too long, and is entirely unhelpful to a casual user. The error reporting from a7f80d402f doesn\u0027t trigger in any combination.\n\nNow here\u0027s how it looks with this patch, when connecting to a 2.7 server before this patch:\n\n2026-04-08 01:34:55 us\u003d526614 Attempting to establish TCP connection with [AF_INET]127.0.0.1:11940\n2026-04-08 01:34:55 us\u003d526683 TCP connection established with [AF_INET]127.0.0.1:11940\n2026-04-08 01:34:55 us\u003d526690 TCPv4_CLIENT link local: (not bound)\n2026-04-08 01:34:55 us\u003d526694 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:11940\n2026-04-08 01:34:55 us\u003d527014 TLS: Initial packet from [AF_INET]127.0.0.1:11940, sid\u003db3756543 a0f9575c\n2026-04-08 01:34:55 us\u003d527030 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this\n2026-04-08 01:34:55 us\u003d527737 VERIFY OK: depth\u003d1, CN\u003dTest CA\n2026-04-08 01:34:55 us\u003d527836 VERIFY OK: depth\u003d0, CN\u003dserver\n2026-04-08 01:34:55 us\u003d568575 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\n2026-04-08 01:34:55 us\u003d568624 [server] Peer Connection Initiated with [AF_INET]127.0.0.1:11940\n2026-04-08 01:34:55 us\u003d568639 TLS: move_session: dest\u003dTM_ACTIVE src\u003dTM_INITIAL reinit_src\u003d1\n2026-04-08 01:34:55 us\u003d568717 TLS: tls_multi_process: initial untrusted session promoted to trusted\n2026-04-08 01:34:55 us\u003d569034 AUTH: Received control message: AUTH_FAILED,Username or password is too long. Maximum length is 128 bytes\n2026-04-08 01:34:55 us\u003d569150 TCP/UDP: Closing socket\n2026-04-08 01:34:55 us\u003d569194 SIGTERM[soft,auth-failure] received, process exiting\n\nIE: the new error path reporting from a7f80d402f actually fires up, and reports a useful and actionable message to the user.\n\nWith a pre-a7f80d402f server there was no helpful message with a patched client, so I\u0027ve now added it.\n\nSo not only this patch doesn\u0027t break compatibility or make the UX worse, it actually improves it in the error case.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"e8bca8de00f5f868a4f27ef5d33936bcfe753c05","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"dfc98cb4_67f761fd","in_reply_to":"2fb6efac_ffe6e6ec","updated":"2026-04-09 01:10:30.000000000","message":"\u003e There are multiple way that I can see that are better suited to solve the problem of supporting longer username/passwords in OpenVPN. They would have many advantages over the approach that you are trying to force in here. They would have only the one downside of not working with the Azure OpenVPN implementation.\n\nWell, that one downside is the one thing I am motivated by...\n\n\u003e I understand that this is frustrating for you but maybe you should complain to Microsoft instead.\n\nEven if there was anybody to complain to (might as well try to complain to a brick wall), using tokens for auth is not going to go away. There are way too many real world security disasters because passwords get exfiltrated or phished and then used to gain permanent access to intranets. JIT single-use tokens are not going anywhere, regardless of any complaint one might make, and they don\u0027t fit in the current hardcoded buffer.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"22dfd69e04189f57f9adb5bafb94154fcd65b86f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"cd213e2b_72f4a63f","in_reply_to":"49f357a0_f3d62688","updated":"2026-04-07 10:26:12.000000000","message":"Sorry, I don\u0027t really follow. This is not a TLS framing issue - the TLS layer (openssl, etc) does its own framing independently of this.\n\nThis is only an issue in the intermediate, local buffer that is used between openvpn and the TLS library.\n\nSo why would this need a protocol update? The on-the-wire format doesn\u0027t change.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"e8bca8de00f5f868a4f27ef5d33936bcfe753c05","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8fbf8c92_4879f2f1","in_reply_to":"4a209db4_0097e79f","updated":"2026-04-09 01:10:30.000000000","message":"\u003e \u003e With a pre-a7f80d402f server there was no helpful message with a patched client, so I\u0027ve now added it.\n\u003e \n\u003e And while you consider that behaviour completely acceptable and the problem that your patch introduces, I really don\u0027t like adding another obscure way an OpenVPN connection can fail. While it might be a not be a big deal for you, you also do not need to debug and support OpenVPN.\n\nBut the problem is not introduced by this patch, it\u0027s always been there, and the logs above intended to show exactly this.\nThe intent of this change is that it doesn\u0027t make it any better or any worse - it simply stays the same: if the server doesn\u0027t support it, you get a clear error message from the client saying so.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"06ea93871da9ac7d02c6800e67ecfca95fe7f4bc","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4a209db4_0097e79f","in_reply_to":"6e70f1de_f80b9722","updated":"2026-04-08 01:42:01.000000000","message":"\u003e With a pre-a7f80d402f server there was no helpful message with a patched client, so I\u0027ve now added it.\n\nAnd while you consider that behaviour completely acceptable and the problem that your patch introduces, I really don\u0027t like adding another obscure way an OpenVPN connection can fail. While it might be a not be a big deal for you, you also do not need to debug and support OpenVPN.\n\n\u003e The error reporting from a7f80d402f doesn\u0027t trigger in any combination.\n\nTo trigger the error reporting of a7f80d402f in earlier version you need a client compiled with --enable-pkcs11 against a server without --enable-pkcs1, ie only accepting passwords of 128 bytes or shorter. As these are not common, as you noticed, it took quite a long time to actually this situation being properly recognised and fixed.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"3b98c9bf5489fa5eb86a3cbcc498c722ac2020ee","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d95b1911_2face597","in_reply_to":"77b32028_9fc15046","updated":"2026-04-08 00:54:40.000000000","message":"\u003e 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.\n\nOf course what I am after is making my use case work, otherwise what would be the point? I don\u0027t think there\u0027s anything wrong with wanting to fix things that don\u0027t work, that\u0027s 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\u0027t feel like it\u0027s a bad goal to have, no?\n\nSo if you have specific suggestions that can improve the situation in _both_ cases, I\u0027d be happy to work on implementing them.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"8acdcd7315dadb2805fa98f03cc2cb91df3ca554","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1a0a3cf2_b0d45c35","in_reply_to":"8a9dd51b_62ceffa3","updated":"2026-04-07 11:54:13.000000000","message":"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. And \"that\u0027s 2 years old\" is way shorter than we care about. We still maintain compatibility with OpenVPN 2.2 server and clients and people are still using a lot of OpenVPN 2.4/OpenVPN 2.5.\n\nAnd that your patch allows triggering very erratic behaviour with these older version is not a good thing.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"8acdcd7315dadb2805fa98f03cc2cb91df3ca554","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"77b32028_9fc15046","in_reply_to":"cd213e2b_72f4a63f","updated":"2026-04-07 11:54:13.000000000","message":"The TLS layer uses TLS records for framing and OpenVPN currently relies on TLS records for its own framing. Not many protocols do this and this also causes problem, ie when you enable record splitting.\n\nAnd your patch basically decides to break this assumption but only for the key2 related methods, which is in my opinion quite hacky.\n\nAnd that why I am saying that we need a proper patch/negotiation to overcome this limit instead. \n\nBut 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.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"22dfd69e04189f57f9adb5bafb94154fcd65b86f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8a9dd51b_62ceffa3","in_reply_to":"d49917cc_8d5c2031","updated":"2026-04-07 10:26:12.000000000","message":"Sure, but that\u0027s 2 years old and included in LTS distros, eg. Ubuntu 24.04 and Debian 13: https://repology.org/project/openvpn/versions\nIt seems very unlikely that older, pre-existing deployments would suddenly start changing existing configuration and attempting to use longer passwords.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"06ea93871da9ac7d02c6800e67ecfca95fe7f4bc","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2fb6efac_ffe6e6ec","in_reply_to":"d95b1911_2face597","updated":"2026-04-08 01:42:01.000000000","message":"There are multiple way that I can see that are better suited to solve the problem of supporting longer username/passwords in OpenVPN. They would have many advantages over the approach that you are trying to force in here. They would have only the one downside of not working with the Azure OpenVPN implementation.\n\nThis is not the first patch/protocol change that has been rejected by the OpenVPN maintainers that is in use for the protocol. See the xor patch for another example.\n\nI understand that this is frustrating for you but maybe you should complain to Microsoft instead.","commit_id":"175292110206fbf3dec35b4a8a6450e2a8f2cf7f"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"672d2ede8a4c03e93da1d35092fca59877616499","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"7bf56249_020d347e","updated":"2026-04-08 02:07:43.000000000","message":"I still do not agree with the approach as such but here are additional some comments on the patch itself.","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"}],"src/openvpn/common.h":[{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"672d2ede8a4c03e93da1d35092fca59877616499","unresolved":true,"context_lines":[{"line_number":73,"context_line":" * Buffer size for key method 2 exchange data. This needs to be"},{"line_number":74,"context_line":" * large enough to hold the key source material, options string,"},{"line_number":75,"context_line":" * username, password and peer info. When USER_PASS_LEN is larger"},{"line_number":76,"context_line":" * than the default TLS channel size (e.g. with ENABLE_PKCS11),"},{"line_number":77,"context_line":" * we need a larger buffer. The key exchange write and read paths"},{"line_number":78,"context_line":" * handle this by doing multiple TLS writes/reads as needed."},{"line_number":79,"context_line":" */"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"a14781fe_894ca37b","line":76,"updated":"2026-04-08 02:07:43.000000000","message":"So an OpenVPN compiled without --enable-pkcs11 gets a buffer of 2048 + 2 * 128? That feels a bit odd.","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"b791faf0fdb645f1493ef611f02a58ea579ba6c8","unresolved":false,"context_lines":[{"line_number":73,"context_line":" * Buffer size for key method 2 exchange data. This needs to be"},{"line_number":74,"context_line":" * large enough to hold the key source material, options string,"},{"line_number":75,"context_line":" * username, password and peer info. When USER_PASS_LEN is larger"},{"line_number":76,"context_line":" * than the default TLS channel size (e.g. with ENABLE_PKCS11),"},{"line_number":77,"context_line":" * we need a larger buffer. The key exchange write and read paths"},{"line_number":78,"context_line":" * handle this by doing multiple TLS writes/reads as needed."},{"line_number":79,"context_line":" */"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"aa56e2af_15c93d1a","line":76,"in_reply_to":"a14781fe_894ca37b","updated":"2026-04-09 01:10:57.000000000","message":"Done","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"}],"src/openvpn/ssl.c":[{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"672d2ede8a4c03e93da1d35092fca59877616499","unresolved":true,"context_lines":[{"line_number":916,"context_line":"            \"payload larger than %d bytes (due to a long password). \""},{"line_number":917,"context_line":"            \"The server may not support large key exchange payloads.\","},{"line_number":918,"context_line":"            TLS_CHANNEL_BUF_SIZE);"},{"line_number":919,"context_line":"    }"},{"line_number":920,"context_line":""},{"line_number":921,"context_line":"    ks-\u003estate \u003d S_UNDEF;"},{"line_number":922,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":2,"id":"a7bf99f1_be645d0f","line":919,"updated":"2026-04-08 02:07:43.000000000","message":"there are other reasons why a handshake can fail at this point. Printing a message that suggest that probably password is at fault can be misleading.","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"e8bca8de00f5f868a4f27ef5d33936bcfe753c05","unresolved":false,"context_lines":[{"line_number":916,"context_line":"            \"payload larger than %d bytes (due to a long password). \""},{"line_number":917,"context_line":"            \"The server may not support large key exchange payloads.\","},{"line_number":918,"context_line":"            TLS_CHANNEL_BUF_SIZE);"},{"line_number":919,"context_line":"    }"},{"line_number":920,"context_line":""},{"line_number":921,"context_line":"    ks-\u003estate \u003d S_UNDEF;"},{"line_number":922,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":2,"id":"7ddd6405_e59c67df","line":919,"in_reply_to":"a7bf99f1_be645d0f","updated":"2026-04-09 01:10:30.000000000","message":"Reworded a bit to make it into a suggestion rather than a statement, can further reword it if needed","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"672d2ede8a4c03e93da1d35092fca59877616499","unresolved":true,"context_lines":[{"line_number":2642,"context_line":" * Read all currently available plaintext from the TLS object into buf,"},{"line_number":2643,"context_line":" * doing multiple reads if necessary. This is used for key method 2"},{"line_number":2644,"context_line":" * exchange data which may exceed a single TLS_CHANNEL_BUF_SIZE read"},{"line_number":2645,"context_line":" * when long passwords/tokens are used."},{"line_number":2646,"context_line":" */"},{"line_number":2647,"context_line":"static bool"},{"line_number":2648,"context_line":"read_incoming_tls_plaintext_multi(struct key_state *ks, struct buffer *buf,"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"ffbce5ce_262ab2e5","line":2645,"updated":"2026-04-08 02:07:43.000000000","message":"So this method will basically greedily read as many TLS records as there are currently on the wire. This will make future improvements a lot harder where there are server/clients out there that basically ignore the framing and consider anything that is sent in the same batch to be part of the key method.\n\nEven the original Microsoft patch does not do that. It still uses only one TLS record (max 16kB) for key2 method. \n\nThe correct approach here would be to try to read a whole TLS record (16 kB) and take whatever the SSL_read gives you as the key2 method and not doing multiple smaller reads that break the assumption of TLS record framing that OpenVPN (currently) uses.\n\nI am surprised that this did not already cause problems for you when the server sends push reply immediately after its key2 write and this is being put into the key packet. But maybe you never got such unlucky timing.","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"e8bca8de00f5f868a4f27ef5d33936bcfe753c05","unresolved":false,"context_lines":[{"line_number":2642,"context_line":" * Read all currently available plaintext from the TLS object into buf,"},{"line_number":2643,"context_line":" * doing multiple reads if necessary. This is used for key method 2"},{"line_number":2644,"context_line":" * exchange data which may exceed a single TLS_CHANNEL_BUF_SIZE read"},{"line_number":2645,"context_line":" * when long passwords/tokens are used."},{"line_number":2646,"context_line":" */"},{"line_number":2647,"context_line":"static bool"},{"line_number":2648,"context_line":"read_incoming_tls_plaintext_multi(struct key_state *ks, struct buffer *buf,"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"cc5a8238_93462793","line":2645,"in_reply_to":"ffbce5ce_262ab2e5","updated":"2026-04-09 01:10:30.000000000","message":"Done","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"672d2ede8a4c03e93da1d35092fca59877616499","unresolved":true,"context_lines":[{"line_number":2937,"context_line":"        }"},{"line_number":2938,"context_line":""},{"line_number":2939,"context_line":"        ks-\u003ekey_method_large_payload \u003d"},{"line_number":2940,"context_line":"            BLEN(\u0026ks-\u003ekey_method_send_buf) \u003e TLS_CHANNEL_BUF_SIZE;"},{"line_number":2941,"context_line":""},{"line_number":2942,"context_line":"        continue_tls_process \u003d true;"},{"line_number":2943,"context_line":"        dmsg(D_TLS_DEBUG_MED, \"STATE S_SENT_KEY\");"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"9a4c89e5_f09f9549","line":2940,"updated":"2026-04-08 02:07:43.000000000","message":"This can also be triggered by other methods like setting multiple setenv UV_xx with push-peerinfo in the configuration and then the user will get the error message iwth the long password above.","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"},{"author":{"_account_id":1000050,"name":"Bluca","email":"luca.boccassi@gmail.com","username":"Bluca"},"change_message_id":"e8bca8de00f5f868a4f27ef5d33936bcfe753c05","unresolved":true,"context_lines":[{"line_number":2937,"context_line":"        }"},{"line_number":2938,"context_line":""},{"line_number":2939,"context_line":"        ks-\u003ekey_method_large_payload \u003d"},{"line_number":2940,"context_line":"            BLEN(\u0026ks-\u003ekey_method_send_buf) \u003e TLS_CHANNEL_BUF_SIZE;"},{"line_number":2941,"context_line":""},{"line_number":2942,"context_line":"        continue_tls_process \u003d true;"},{"line_number":2943,"context_line":"        dmsg(D_TLS_DEBUG_MED, \"STATE S_SENT_KEY\");"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"0a3fd2a0_be58e8fd","line":2940,"in_reply_to":"9a4c89e5_f09f9549","updated":"2026-04-09 01:10:30.000000000","message":"Doesn\u0027t push_peer_info() hardcode a limit of 512 * 3, which is lower than 2048 anyway? Could you please share a config that would reproduce this issue?","commit_id":"74d3e3d845b9be1f703a20f4b70e82cacae77682"}]}