Hi William, That’s exactly the kind of feedback I was after, thanks. Creating the ability to load a PKCS#11 URI from the PEM and then providing that information over some socket to a separate service to handle it should work well and avoid the complexity of implementing the threading model within HAProxy as I have done in this patch. As I did it I really disliked it, which is why I was after feedback in the first place.
Originally I hoped to make use of p11-kit to do exactly this: https://github.com/p11-glue/p11-kit. However, the external interface for it is itself a PKCS#11 module (p11-kit-client.so <http://p11-kit-client.so/> which is blocking). However, this interfaces with the p11-kit server over a UNIX socket and I believe I can simply take the synchronous code from the client and make it asynchronous within HAProxy. The entry point for their client is here: https://github.com/p11-glue/p11-kit/blob/master/p11-kit/client.c. I don’t suppose it’s all that complex to provide support for the few functions required to do signing. There’s a lot of PKCS#11 functionality that I don’t think we care about at all. What do you think about that for a solution before I take a crack at it? Thanks, Chris. > On 18 Aug 2025, at 14:43, William Lallemand <[email protected]> wrote: > > 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 > <https://isolate-menlo.menlosecurity.com/readonly/http://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
