OpenSSL Security Advisory [7th February 2023]

https://www.libressl.org/

At the AWS cryptography group, we've open-sourced our libcrypto - https://github.com/awslabs/aws-lc - which essentially tries to use the best from Google's BoringSSL, OpenSSL (from 1.1x , not 3.x) , our own code, and formal verification and does target a broad set of platforms and is our FIPS module.

We're at about 95% OpenSSL compatibility right now, it "just works" for a lot of applications, and I expect we'll get near-full compatibility this year as we switch more and more of our own systems to using it internally.

We don't promote it broadly, and it's not intended to compete with OpenSSL - but it's a may be an interesting option for some to consider.

Future of Memory Safety Challenges and Recommendations https://advocacy.consumerreports.org/wp-content/uploads/2023...

""" Case Studies 1. The Python cryptographic authority is one of the most widely used cryptography libraries in the Python ecosystem. Many of the tools are largely built on OpenSSL. The popular cryptography library is written in C. About two years ago, the maintainers started the process of migrating some of their dependence on OpenSSL away from that to their own Rust code, particularly starting with areas around certificate parsing and parsing of other structures. These are some of the most classical places to find memory safety vulnerabilities in C libraries, and they wanted to mitigate the risk that they were having by relying on OpenSSL.

Another benefit was getting huge performance improvements, because the greater safety guarantees they were getting from the language allowed them to be more aggressive in doing things like not copying memory. Specifically, the safety guarantees of Rust mean that one can easily represent structures like X.509 certificates as an array of bytes, and then a parsed structure containing pointers into the original array. ... """