On 5/21/25 00:04, Willy Tarreau wrote: > Hi, > > On Tue, May 20, 2025 at 08:40:06PM -0400, Demi Marie Obenour wrote: >> I tried to implement a toy OpenID Connect relying party >> using Lua scripting, and ran into a few problems: >> >> 1. I could not figure out a safe way to use the aes_gcm_enc >> and aes_gcm_dec converters. There's no way to generate a >> strong random number, and the 96-bit AES-GCM nonce size >> means one would need to use a per-HAProxy-instance key. >> This is not compatible with active-active clustering. >> One could implement something SIV-like by using HMAC of >> the data to generate the key, but the use of base64 encoding >> for the key suggests that there might be a timing leak unless >> the base64 code is constant time. > > What do you think you would need ? For randoms, what do you qualify > as strong random numbers for example ?Is it based on the period > length ? On the way it's seeded ? Right now our PRNG has a 2^128 bits > period and is seeded from: time, pid, ppid, urandom, RAND_bytes() when > openssl is available, random(), ASLR, execution time, and host name, > i.e. about everything we can locally collect that can differ between > boots and machines.
“Strong” means “suitable for cryptographic purposes”. The simplest approach would be to get random numbers directly from OpenSSL, and to use XChaCha20-Poly1305 with a random nonce for the encryption. The XChaCha20-Poly1305 nonce is long enough that it can be generated at random. > And for base64, if the output of the HMAC is of > fixed size, base64 will be as well, so the part of the string used > to construct it will be made of only table lookups. If your concern > is that this property is not guaranteed over time, I can understand, > but then we could simply add a comment on top of the function to > mention that the processing time per input byte must remain constant. Table lookups are vulnerable to timing attacks, as shown by Daniel J. Bernstein in 2005 [1]. libsodium has a constant-time base64 decoder under a permissive license. [1]: https://cr.yp.to/antiforgery/cachetiming-20050414.pdf >> 2. The jwt_verify converter requires a literal certificate name, >> which won't work if the certificate is fetched at runtime by >> Lua (perhaps from a Valkey (Redis clone) database). > > For this I really don't know (I'm still ignorant of these things). > However I'm seeing in the doc that it takes either a certificate > name or a secret. I don't know how this is differentiated, but I'm > also aware that William has plans for supporting "virtual certs", > i.e. some that are not stored on the FS (typically for generating > new ones on the fly). I don't know which parts of this are already > implemented and usable, but it seems to me that this could possibly > be one approach to what you're looking for, with that cert pre-loaded > into the cert store. Could these be updated by Lua code at runtime? Or would it be best to send requests that don't already have a valid session cookie to a different server? >> Is there a good way to implement OpenID Connect via Lua scripting, >> or is this something that would be better supported natively in >> HAProxy's C code or handled via SPOE? > > For this I have no idea either :-/ Theoretically we try to permit to > do about everything in Lua but we're also aware that some bindings > might be missing and that we have to add new ones. Thus ideally I > think it could be useful to try to spot the missing (or problematic) > parts in the approach you were considering so that we see if it can > be improved easily. Is loading a Lua module written in C an option? Obviously that can’t be done at runtime, but would it make sense to do that at startup? -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
