This issue is caused by duplicate OpenSSL symbols.

Due to the way ELF linkage and loading works on Linux, Themis may be using OpenSSL functions different from the ones it was compiled. ABI mismatches are sometimes unnoticeable, sometimes lead to crashes, and sometimes lead to unexpected behavior.

⚠️ Warning:
Using JsThemis with prebuilt Themis Core packages may be not safe. If you can, please build Themis Core from source for now.

How linkage should work

Normally, JsThemis addon uses Themis Core libraries installed from binary packages hosted by Cossack Labs. We build there packages for various distros, using the OpenSSL package provided by the distro. That way JsThemis gets all security updates in OpenSSL essentially for free, from a package maintained by distro maintainers.

This is how linkage and installation should look in the ideal case:

Node.js loads JsThemis, which uses Themis which uses Soter which uses OpenSSL installed into the system.

How it actually works (or doesn't)

Node.js binary includes its own copy of OpenSSL inside it. It has been like this historically, and it is important for some native add-ons which expect OpenSSL to be available with just Node.js.

However, due to way symbol lookup works on Linux, this is what happens:

Soter uses OpenSSL functions from the Node.js binary, not the ones from system’s OpenSSL. It is still loaded, but mostly ignored after that.

Sometimes it is fine since OpenSSL does a good job at keeping ABI compatibility. However, if Node.js was built with a different version of OpenSSL than the one installed in the system, then ABI mismatch may happen. Data structures will have different layout, function implementations may be different, etc. This causes undefined behavior, most likely leading to a crash.

Though, if OpenSSL versions in system and Node.js match then JsThemis will kinda work fine.

What we are planning to do

Unfortunately, we can’t change the way linkage works on Linux. And we can’t remove OpenSSL from Node.js. Therefore, we are planning to switch to the following scheme in a future release:

By using embedded BoringSSL, Soter will use the library it was built with, avoiding the possibility of symbol clash and ABI mismatch.

This approach is tracked in issue #619.

Alternatives

Another way this issue can be solved is to link Soter against Node.js OpenSSL:

This will avoid duplicating cryptographic code in memory (due to OpenSSL and BoringSSL being loaded), but it’s not really practical for us. We’d have to build Themis for each individual Node.js version. Then we’d need to teach the users to install a version of Themis that matches their Node.js installation (or have the users build Themis from source). This is not very convenient, both for us and the users.

Furthermore, using BoringSSL allows us to issue security updates to Themis independently of Node.js security updates.