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, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.