[PATCH] MEDIUM: ssl: add support for using cryptographic keys stored in a PKCS#11 HSM (no replies)

Hi,

This patch enables the use of cryptographic keys stored in a
PKCS#11-compatible hardware security module. It uses the OpenSSL engine
interface, and has been tested with engine-pkcs11 and two different
kinds of HSM:

- SoftHSM
- Yubikey

The main benefit of storing cryptographic keys in a HSM is to prevent
them from being accessed or stolen should the host been compromised, by
example using a heartbleed-like vulnerability. Note that while being
very useful for testing purpose, SoftHSM keeps the key in the same
memory space than the main process, and a such should not be considered
as secure as an hardware HSM. While a Yubikey is a nice device and a
hardware HSM, it provides a very low transactions/s rate, and as such
might probably not be suited for production use with HAproxy.

This patch should be considered more a proof-of-concept/WIP than a
production-ready one. It adds the possibility to load a private key from
a HSM while the corresponding certificate is still loaded from a file,
using the following syntax:

bind 127.0.0.1:8443 ssl crt pkcs11:slot_<SLOT NUMBER>-id_<OBJECT
ID>:/path/to/corresponding/cert.pem

For example, this would load the private key from the object named
deadbeef in the slot 0 of softhsm:

bind 127.0.0.1:8443 ssl crt
pkcs11:slot_0-id_deadbeef:/path/to/corresponding/cert.pem

Or from the slot 9a of a yubikey in PIV mode:

bind 127.0.0.1:8443 ssl crt
pkcs11:slot_1-id_1:/path/to/corresponding/cert.pem

This patch also allows the configuration of the OpenSSL application name
via the environment variable HAPROXY_SSL_APP_NAME, in order to use
different configurations for different applications without polluting
the default OpenSSL namespace.

For these examples to work, engine-pkcs11 must be installed and OpenSSL
be configured to use it. For example, these sections can be defined in
/etc/ssl/openssl.conf:

haproxy_yubi_conf = haproxy_yubi_def
haproxy_shsm_conf = haproxy_shsm_def

[...]

[haproxy_yubi_def]
engines = engine_ha_yubi_section

[engine_ha_yubi_section]
pkcs11 = pkcs11_ha_yubi_section

[pkcs11_ha_yubi_section]
engine_id = pkcs11
dynamic_path = /usr/lib/engines/engine_pkcs11.so
init = 0
MODULE_PATH = /usr/lib/pkcs11/opensc-pkcs11.so

[haproxy_shsm_def]
engines = engine_ha_shsm_section

[engine_ha_shsm_section]
pkcs11 = pkcs11_ha_shsm_section

[pkcs11_ha_shsm_section]
engine_id = pkcs11
dynamic_path = /usr/lib/engines/engine_pkcs11.so
init = 0
MODULE_PATH = /usr/lib/libsofthsm.so

In this example, in order to load keys from SoftHSM,
HAPROXY_SSL_APP_NAME has to be set to "haproxy_shsm_conf". For loading
from a yubikey (via OpenSC), HAPROXY_SSL_APP_NAME has to be set to
"haproxy_yubi_conf".

There is a few things I am not happy with in this patch:
- the hijacking of the crt syntax, prepending "pkcs11:" to load the key
from a PKCS#11 engine ;
- the use of a environment variable to specify the OpenSSL application
name. However it has to be set before __ssl_sock_init() constructor is
loaded, so the configuration parsing has not been done yet ;
- the PKCS#11 interface specifies that all PKCS#11 handles should be
reinitialized after a fork(), which might be an issue with nbproc > 1.
In practice this is correctly handled by some drivers but it's not
guaranteed to work for every one of them.

I will appreciate any feedback regarding those points or the patch itself.

--
Remi