[M] Change in openvpn[master]: ssl: use TLS record-sized buffers for key method 2 exchange

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: ssl: use TLS record-sized buffers for key method 2 exchange
......................................................................


Patch Set 2:

(5 comments)

Patchset:

PS1: 
> > With a pre-a7f80d402f server there was no helpful message with a patched client, so I've now added it.
> 
> And while you consider that behaviour completely acceptable and the problem that your patch introduces, I really don't 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.

But the problem is not introduced by this patch, it's always been there, and the logs above intended to show exactly this.
The intent of this change is that it doesn't make it any better or any worse - it simply stays the same: if the server doesn't support it, you get a clear error message from the client saying so.


PS1: 
> 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.

Well, that one downside is the one thing I am motivated by...

> I understand that this is frustrating for you but maybe you should complain to Microsoft instead.

Even 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't fit in the current hardcoded buffer.


File src/openvpn/ssl.c:

http://gerrit.openvpn.net/c/openvpn/+/1622/comment/7ddd6405_e59c67df?usp=email :
PS2, Line 919:     }
> there are other reasons why a handshake can fail at this point. […]
Reworded a bit to make it into a suggestion rather than a statement, can further reword it if needed


http://gerrit.openvpn.net/c/openvpn/+/1622/comment/cc5a8238_93462793?usp=email :
PS2, Line 2645:  * when long passwords/tokens are used.
> So this method will basically greedily read as many TLS records as there are currently on the wire. […]
Done


http://gerrit.openvpn.net/c/openvpn/+/1622/comment/0a3fd2a0_be58e8fd?usp=email :
PS2, Line 2940:             BLEN(&ks->key_method_send_buf) > TLS_CHANNEL_BUF_SIZE;
> This can also be triggered by other methods like setting multiple setenv UV_xx with push-peerinfo in […]
Doesn't 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?



-- 
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: Thu, 09 Apr 2026 01:10:30 +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