On Thu, Aug 14, 2025 at 02:55:24PM +0100, Christopher Staite wrote: > Subject: Re: [PATCH] FEATURE: pkcs11: add support for PKCS#11 > Hi WIlliam, > > With HAProxy Conf and HAProxy 3.2 out of the way, I was wondering if you had > some time to give this a look over? > > Thanks, Chris. >
Hi Christopher, Sorry for the late reply, we took a look with Willy today in order to check what could be mergeable and what is not possible with our model. Loading a PKCS11 key file containing the provider URI from the configuration seems like a good idea, I didn't check if this is still compatible with the dynamic operations on the CLI though, but if not, we could probably disable them for that type of keys. We could even have a keyword to specify the PKCS11 URI instead of using a PEM for this, this was asked by several people multiple time, but we didn't wanted to implement half of the features so this was never done. Stopping the handshake upon SSL_ERROR_WANT_PRIVATE_KEY_OPERATION and waking up a task to achieve the PKCS11 operations seems to be the right way to do this. The biggest challenge with dealing with a HSM is the blocking operations, and the way you handled it might be problematic. We must not have threads in haproxy that are outside the haproxy threads, the thread configuration is precise and allow to configure NUMA machine automatically for example, to specify binding of cores etc. It will deviate from our model and will be complicated to maintain if we do it this way. I know that there is already the same problems with engines and providers that pop threads, but unfortunately that's already a problem for us. The loading of a .so is also a thing that we don't want to introduce, for maintenance as well as security reasons. A .so might try to do anything like forking, threading, accessing files. This may add a lot of pressure on the maintainers giving the amount of bugs external modules could introduces. I don't think the current architecture of haproxy is ready to handle the PKCS11 the way you did, however we could simplify the haproxy part. There might be a way to deal with this properly with our model. We could externalize the PKCS11 part in a daemon which would load the pkcs11.so and would expose a UNIX socket. And HAProxy would communicate over this non-blocking UNIX socket each time we receive an SSL_ERROR_WANT_PRIVATE_KEY_OPERATION. We could even have one socket configured in HAProxy per driver. I'm not a PKCS11 expert, but I know that people already implemented PKCS11 operations over the network and doing PKCS11 forwarding. That might be a better solution for this. What do you think? Regards, -- William Lallemand
