> Support for using the Windows system certificate store as a source of trusted root certificates. This is not yet enabled by default and must be activated using an environment variable. This is likely to become enabled by default in a future feature release.
OpenSSL is used for TLS in tons of software ported from Linux to Windows.
True and concerning. LibreSSL has been leading the pack in terms of security, but I wouldn't even call it bulletproof. These are very complicated codebases. I'd love to see OpenSSL adopt an approach of "useful features, tested well, and nothing else" but that's basically why LibreSSL was born after heartbleed. So I won't hold my breath.
Personally, I’d like to see a slower addition of features in something as critical as OpenSSL.
LibreSSL (part of the OpenBSD project) has been aggressively pruning and hardening the codebase and is not immune to bugs. Security in crypto libraries is very hard.
OpenSSL is the kitchen sink for relatively well validated, fast crypto primitives, yet every project that uses one of those has to include the other couple megs of libcrypto (most of that is in ASN1 and X509 implementations, which are libcrypto and not libssl). Certainly seems to me like there's room for a librealcrypto (ought to fit in well under a meg) and a libitutils (all that X509 stuff).
OpenSSL is historically also the kitchen sink for TLS features and extensions, with rather mixed results.
> Support for using the Windows system certificate store as a source of trusted root certificates. This is not yet enabled by default and must be activated using an environment variable. This is likely to become enabled by default in a future feature release.
OpenSSL is used for TLS in tons of software ported from Linux to Windows.