Hi, Been poking around the edges of this on the side for some time now.
I keep looking at p11-kit and then getting put off. I contacted them about how they would feel about this integration and they did not reply. The RPC protocol is internal and could change between versions. I’m not a fan of that. Therefore I’ve come up with the conclusion that the solution here would be to have HAProxy fork at start-up if this is enabled in the global configuration and then execute all of the PKCS#11 synchronous code in that forked process. This could then communicate with the main process over a socket that was established when it forked. The forking mechanism doesn’t allow the offloading as discussed elsewhere in this thread, so perhaps we have a separate daemon distributed with HAProxy to provide this. Essentially re-implementing p11-kit (unfortunately), but in a limited manner for just the required functions for this feature. Before I go down that road I thought I’d re-visit the list for feedback. Thanks, Chris. > On 19 Aug 2025, at 10:55, Willy Tarreau <[email protected]> wrote: > > 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 > > > <https://isolate-menlo.menlosecurity.com/readonly/http://p11-kit-client.so> > > > <http://p11-kit-client.so/ > > > <https://isolate-menlo.menlosecurity.com/readonly/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 > > <https://isolate-menlo.menlosecurity.com/readonly/http://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
