Hi guys, sorry for not jumping in earlier, but I agree with what was discussed for now.
On Tue, Aug 19, 2025 at 11:44:26AM +0200, William Lallemand wrote: > > 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? > > I didn't check everything which is provided by the PKCS#11 spec but indeed > that could be enough to do only the signing. > What's important is that we don't depend on external code on haproxy side. > Having the p11-kit server loading the .so > driver for the HSM, and exposes a UNIX socket seems perfect. So HAProxy just > have to implement the client side of > it. By the way, Chris, just like you planned to dedicate multiple threads to that part, it would make sense to support multiple connections to the deamon, at least to let it scale and to avoid head-of-line blocking etc. I think that in terms of configuration, since you have a driver mentioned in the .pem, the most natural way to configure this would be to permit to designate a list of drivers -> socket path + #conn. For example (just made up, don't take my words for that): global pkcs11-driver dummy /var/run/pkcs11-dummy.sock nbconn 10 pkcs11-driver real /var/run/pkcs11-real.sock nbconn 100 Maybe over time we'll figure that it can even be useful to support remote systems (I don't know, but I wouldn't be surprised if high-traffic users would prefer to have smaller LBs and larger crypto machines for example since it will offload the expensive asymmetric crypto operations there). Logically in terms of haproxy at run time it will not change anything to use unix or TCP sockets. But I know the devil is always in the details. That's why I'm mentionning it to help with the design without making this a prerequisite :-) > I just hope that we don't need to define specifics things for each drivers on > the client side. But yes, if an equivalent > of p11-kit-client.so in non-blocking mode within haproxy is implemented, that > would be an elegant way of achieving the > feature and it could work with multiple implementations of the protocol! Yes I think so as well! Regards, Willy
