[sr-dev] [kamailio/kamailio] OpenSSL 1.1.1 and HSM keys incoming patches (#2839)

aalba6675 notifications at github.com
Wed Sep 1 00:16:27 CEST 2021


### Description

When using HSM keys (via OpenSSL engine) the engine and private keys are loaded in the child processes since PKCS#11 modules rarely survive `fork()`.

With OpenSSL 1.1.1 and the call to `OPENSSL_init_ssl()` in `tls_init.c` the engine linked-list is now initialized in the master process. Subsequently the technique used in `tls_init.c:660 CONF_modules_load_file()` will fail as each child process manipulates the linked-list. Even if the engine linked-list manipulation itself is protected by global locks; traversing the linked-list will encounter invalid memory locations as the nodes are insert by other child processes.

This issue is filed as a marker; I will be providing patches to change the way HSM private keys are loaded in the child process to avoid linked-list corruption.

### Troubleshooting

- use soft (PEM) keys — no issue as OpenSSL engine is not relevant in this context


#### Reproduction

- configure TLS with OpenSSL engine key(e.g pkcs11 engine with SoftHSM keys)


### Additional Information

Root cause: the function `CONF_modules_load_file()` will configure OpenSSL engines from a OpenSSL configuration file but it also adds each engine to the  global linked list. Unfortunately there is no OpenSSL function to reset the linked-list in the child process. It seems to be initialized once at start-up: the linked-list head/tail pointers are static variables and their initialization is protected by OpenSSL's `RUN_ONCE` mechanism, so it doesn't seem it supported mechanism to have them reinitialized after `fork()`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2839
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20210831/e7017b8a/attachment.htm>


More information about the sr-dev mailing list