Nim: Make SSL/TLS implementation pluggable

[snej]

Summary

Nim's TLS/SSL support is currently hardwired to use OpenSSL. Some programs may want to use alternate APIs (mbedTLS, wolfSSL, bearSSL, SecureTransport, etc.) for reasons of footprint, compatibility, security, etc. This should be possible without having to modify code in the standard library.

Description

Refactor Nim's socket implementation to split out the OpenSSL-dependent code and put a well-defined API in between, with a mechanism to swap in different implementations of that API, whether in the standard library or application-defined.

Additional Information

Forum comment by leorize:

the [TLS] implementation is currently integrated with net.Socket. You can open an issue on GitHub requesting a pluggable mechanism and I might look into it. It's not really that hard to replace the current system with a pluggable one, it's just that there aren't enough interest to go for it atm.

[snej]

FYI, I'm motivated to work on this. If my team ends up choosing Nim to implement a project I'm speccing, we will probably need to use mbedTLS. I'm new to Nim but have a lot of experience with networking in C/C++.

[dom96]

Go for it. Just make sure changes are well tested.

[alaviss]

We will probably want #14556 in before getting started on this.

[FedericoCeratto]

After OpenSSL, GnuTLS appears to be relatively popular, followed by mbedTLS, according to statistics on Debian.
Yet, supporting multiple implementations, doing extensive testing, and maintaining them for whole lifetime of the libraries is quite a big amount of work. Are there other programming languages doing that as part of the stdlib?

[alaviss]

We really just need to make it pluggable. External implementations can be provided by 3rd party packages.

[snej]

Are there other programming languages doing that as part of the stdlib?

Go implemented its own TLS package, in keeping with its extreme NIH tendency.

Rust has native_tls which wraps the platform's TLS library, "SChannel on Windows (via the schannel crate), Secure Transport on OSX (via the security-framework crate), and OpenSSL (via the openssl crate) on all other platforms". But it does not appear to be part of the standard library as its repo is outside the Rust org on Github.

[AZ-X]

Please support this issue.