| Message ID | 20260315184337.1541272-2-luca.boccassi@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Two small fixes for auth via tokens | expand |
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
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
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
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 --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 *