diff mbox series

[Openvpn-devel,1/2] Increase TLS_CHANNEL_BUF_SIZE from 2048 to 8192

Message ID 20260315184337.1541272-2-luca.boccassi@gmail.com
State New
Headers
Series Two small fixes for auth via tokens |

Commit Message

Luca Boccassi March 15, 2026, 6:39 p.m. UTC 
  From: Luca Boccassi <luca.boccassi@gmail.com>

When authenticating via a JWT token 2048 bytes are not enough, which
breaks the auth process. In my local case the token is ~2100 bytes.
Bump the maximum harcoded size from 2k to 8k to leave some headroom.

Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
---
 src/openvpn/common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Arne Schwabe March 16, 2026, 11:57 a.m. UTC | #1 
Am 15.03.26 um 19:39 schrieb luca.boccassi@gmail.com:
> From: Luca Boccassi <luca.boccassi@gmail.com>
> 
> When authenticating via a JWT token 2048 bytes are not enough, which
> breaks the auth process. In my local case the token is ~2100 bytes.
> Bump the maximum harcoded size from 2k to 8k to leave some headroom.

This is a change that can break compability. The normal limit is only 
128 bw.

#define USER_PASS_LEN 128

Overall things like such big data should really be implemented via 
auth-pending method or similar.

Arne
Luca Boccassi March 16, 2026, noon UTC | #2 
On Mon, 16 Mar 2026 at 11:57, Arne Schwabe <arne@rfc2549.org> wrote:
>
> Am 15.03.26 um 19:39 schrieb luca.boccassi@gmail.com:
> > From: Luca Boccassi <luca.boccassi@gmail.com>
> >
> > When authenticating via a JWT token 2048 bytes are not enough, which
> > breaks the auth process. In my local case the token is ~2100 bytes.
> > Bump the maximum harcoded size from 2k to 8k to leave some headroom.
>
> This is a change that can break compability. The normal limit is only
> 128 bw.
>
> #define USER_PASS_LEN 128

The length is actually 4K when PKCS11 is enabled, which is the case in
most distros:

/* max length of username/password */
#ifdef ENABLE_PKCS11
#define USER_PASS_LEN 4096
#else
#define USER_PASS_LEN 128
#endif

Could you please clarify how bumping this buffer max size could break
compatibility? Thanks

> Overall things like such big data should really be implemented via
> auth-pending method or similar.

Do you have more references available for this, please? Thanks
Arne Schwabe March 16, 2026, 12:09 p.m. UTC | #3 
Am 16.03.26 um 13:00 schrieb Luca Boccassi:
> On Mon, 16 Mar 2026 at 11:57, Arne Schwabe <arne@rfc2549.org> wrote:
>>
>> Am 15.03.26 um 19:39 schrieb luca.boccassi@gmail.com:
>>> From: Luca Boccassi <luca.boccassi@gmail.com>
>>>
>>> When authenticating via a JWT token 2048 bytes are not enough, which
>>> breaks the auth process. In my local case the token is ~2100 bytes.
>>> Bump the maximum harcoded size from 2k to 8k to leave some headroom.
>>
>> This is a change that can break compability. The normal limit is only
>> 128 bw.
>>
>> #define USER_PASS_LEN 128
> 
> The length is actually 4K when PKCS11 is enabled, which is the case in
> most distros:
> 
> /* max length of username/password */
> #ifdef ENABLE_PKCS11
> #define USER_PASS_LEN 4096
> #else
> #define USER_PASS_LEN 128
> #endif
> 
> Could you please clarify how bumping this buffer max size could break
> compatibility? Thanks

The 128 vs 4096 is already problematic at times. Adding a third size 
does not help. Also the real password size that is useable in user/pass 
is not 4k either. Even with the 2048 that you want, you will run into 
problem because of other limitations, e.g. that the packet that 
user+pass and peer info variables a bit of other stuff needs to be is 
limited to 2048 bytes in total.

If we really want to support longer username and password 
authentication, this needs to be implemented in a different way that is 
not so problematic. E.g. client indicating its support for the extended 
password+username stuff (e.g. via IV_SSO) and then switching to that method.


>> Overall things like such big data should really be implemented via
>> auth-pending method or similar.
> 
> Do you have more references available for this, please? Thanks

See management.txt as a start.

Arne
Luca Boccassi March 16, 2026, 8:17 p.m. UTC | #4 
On Mon, 16 Mar 2026 at 12:09, Arne Schwabe <arne@rfc2549.org> wrote:
>
> Am 16.03.26 um 13:00 schrieb Luca Boccassi:
> > On Mon, 16 Mar 2026 at 11:57, Arne Schwabe <arne@rfc2549.org> wrote:
> >>
> >> Am 15.03.26 um 19:39 schrieb luca.boccassi@gmail.com:
> >>> From: Luca Boccassi <luca.boccassi@gmail.com>
> >>>
> >>> When authenticating via a JWT token 2048 bytes are not enough, which
> >>> breaks the auth process. In my local case the token is ~2100 bytes.
> >>> Bump the maximum harcoded size from 2k to 8k to leave some headroom.
> >>
> >> This is a change that can break compability. The normal limit is only
> >> 128 bw.
> >>
> >> #define USER_PASS_LEN 128
> >
> > The length is actually 4K when PKCS11 is enabled, which is the case in
> > most distros:
> >
> > /* max length of username/password */
> > #ifdef ENABLE_PKCS11
> > #define USER_PASS_LEN 4096
> > #else
> > #define USER_PASS_LEN 128
> > #endif
> >
> > Could you please clarify how bumping this buffer max size could break
> > compatibility? Thanks
>
> The 128 vs 4096 is already problematic at times. Adding a third size
> does not help. Also the real password size that is useable in user/pass
> is not 4k either. Even with the 2048 that you want, you will run into
> problem because of other limitations, e.g. that the packet that
> user+pass and peer info variables a bit of other stuff needs to be is
> limited to 2048 bytes in total.

Please note that this patch does not add a third password size? It
removes the second one, leaving the existing 4096 as the sole option
one, by dropping the ifdef. I don't strictly need this, as all distros
build with PKCS11 support enabled anyway so this works fine for my use
case too out of the box, but I thought it would have been nice to
reduce the variance.
diff mbox series

Patch

diff --git a/src/openvpn/common.h b/src/openvpn/common.h
index aa7b7217..fbe6239a 100644
--- a/src/openvpn/common.h
+++ b/src/openvpn/common.h
@@ -67,7 +67,7 @@  typedef unsigned long ptr_type;
  * maximum size of a single TLS message (cleartext).
  * This parameter must be >= PUSH_BUNDLE_SIZE
  */
-#define TLS_CHANNEL_BUF_SIZE 2048
+#define TLS_CHANNEL_BUF_SIZE 8192
 
 /* TLS control buffer minimum size
  *