An often-quoted open source statistic is that 80% or more of products will have elements of open source in them. Recently Gartner stated that “open-source software (OSS) is used within mission-critical IT workloads by more than 95% of IT organizations worldwide, whether they are aware of it or not” (A CTO’s Guide to Open-Source Software: Answering the Top 10 FAQs September 2022 – ID G00776470).
If you use Transport Layer Security (TLS), you’re probably using open source again in the form of an instance of an OpenSSL implementation. OpenSSL provides a toolkit to support cryptography, TLS communication, and digital certificate management. It’s deployed as part of most major operating systems, such as RedHat, Debian, MacOS, and Oracle’s Linux. OpenSSL is often used with web servers, such as NGINX and Apache, when HTTPS is required. You can find it on everything from supercomputers to embedded systems. It’s even running on a Rover on the surface of Mars.
OpenSSL shows up everywhere and is a key technology in helping to secure communication for cloud-based services and the underlying OS. Oracle has adopted OpenSSL as a strategic library to provide cryptographic data and communications security. Oracle could implement its own cryptography software stack for its products, but that would mean missing out on the benefits of Linus’ Law: The idea that the more people engaged in using and maintaining a code base, the more easily bugs can be found. If a bug is found, interest in fixing the bug as quickly as possible increases. These characteristics are all highly desirable for software central to providing security.
Oracle’s work with OpenSSL doesn’t end with simply adopting it. Given that OpenSSL is so central to the security of our products, it’s only right for us to help maintain it. Open source teams embrace community participation, and we care about contributing code that meets Oracle’s requirements and helps the community as a whole. To maintain its position as the world’s foremost cryptographic toolkit, OpenSSL needs to evolve with security standards, implement new cryptographic primitives, and quickly address any vulnerabilities found by the community. As an active participant and contributor to the community, Oracle supports activities to keep OpenSSL secure. In practical terms, this aim means several things, but the main goal is the engineering effort.
OpenSSL recently completed a major journey to reengineer its internals, moving from a cryptographic toolkit to a cryptographic framework for greater modularity and extensibility. Oracle was part of the core development team that implemented these changes in OpenSSL 3.0. The API changes were minor, so anyone using OpenSSL experienced low impact. The new architecture allows OpenSSL to modularize regulatory compliance code for Federal Information Processing Standard Publication (FIPS) 140, making updates easier as the FIPS standards evolve and isolating those changes from other parts of OpenSSL for the users that don’t care about FIPS.
The modularity also allows organizations to plug in their own cryptographic implementations in modules known as providers, such as experimental post-quantum cryptography, which hasn’t completed standardization, or niche solutions that aren’t suitable for the wider community. This modularity makes OpenSSL customizable without requiring a fork of the code. Such significant changes aren’t just a coding effort but require involvement with OpenSSL’s core development team, the OpenSSL Technical Committee (OTC), which is made up of eleven members, including one from Oracle.
Participation in the technical committee comes from being nominated to the role by the OpenSSL team because of being recognized as a knowledgeable, skilled, and hardworking contributor for the benefit of all. Oracle’s representation on the OTC reflects the depth of commitment being made.
Oracle doesn’t get involved with every major feature, but we like to help with each release, even on mundane tasks like improving OpenSSL’s tests. We’re part of the community, so if it’s good for the community, it’s good for our business too. When something particular piques our interest, like FIPS 140, we understand that the solution must be engineered to benefit everybody, like moving to a crypto framework to modularize FIPS 140.
Why is compliance with FIPS 140 crucial? FIPS sets out the requirements and classifications for cryptographic solutions, such as the use of approved algorithms, as defined by the National Institute of Standards and Technology (NIST). Oracle prides itself on offering secure solutions, but only an independent attestation to compliance with defined requirements can demonstrate it’s secure. For more sensitive environments, having that attestation is a must. For example, the Federal Risk and Authorization Management Program (FedRAMP) provides a standardized way for federal services to cost-effectively risk assess the adoption of cloud services, and part of that assessment is the ability to meet the FIPS 140 requirements. To this end, Oracle was a sponsor and code contributor for the OpenSSL FIPS validation effort.
Like Oracle’s contributions to the Linux kernel, this work might not gain the profile of projects such as those supported by the Cloud Native Computing Foundation (CNCF). Still, the work is essential for the security of IT systems everywhere and crucial for enabling cloud adoption.
In reading this blog post, you have made use of OpenSSL. To learn more about OpenSSL, visit OpenSSL.