On Thu, May 22, 2025 at 09:49:20PM -0400, Demi Marie Obenour wrote: > > 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.
Then we'd need a separate strong_random() function that is only available when openssl is enabled. > > 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 Thanks for the link. With that said, the attack described above only works because the tables do not fit in a cache line. For base64 the tables are a single cache line (64B). But we could pretty well replace our implementation with a constant time one if needed. From memory we have two implementations, the normal one and a URL-safe one. But do not hesitate to have a look at its replacement. If you need to import a file from libsodium, please place it in src/ for .c, or in include/import/ for .h, and try to change the least possible files there so that it's possible to update from time to time (like we do for xxhash, slz, trees etc). Otherwise if it's just a matter of replacing a function or two, it's OK to just copy them into base64.c, but then please mention in the comment on top of the function where it comes from (both to help check for updates and for crediting the original author). > >> 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? I don't know. We could ask William but he's busy finishing his presentation for the conference next week, so better see this after the conference (or maybe at the conference if you go there). > >> 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? I know that some do it to extend haproxy, but your C code needs to be careful not to make blocking calls nor to take too much time. That's the problem with calling external code, you need to be certain it was designed with extremely low latency in mind (and the reason why some existing Lua libs are causing problems). I don't know how that fits with lua-load-per-thread by the way. At the very least it can be an option to easily experiment with extra code without having to patch haproxy. Another option for testing is to rely on LD_PRELOAD, but then you need to be super careful to respect the exact internal API and ABI (any build option counts). Regards, willy
