### 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