Support building OpenSSL for Ruby with AWS-LC

[samuel40791765]

Hello,

I’m an engineer at AWS working on AWS-LC, AWS’s open-source cryptographic library maintained for AWS and their customers. AWS-LC supports CPU-specific performance optimizations for AWS Graviton 2, AWS Graviton 3, and Intel x86-64 with AVX-512 instructions. We’ve formally verified a subset of AWS-LC’s cryptographic primitives, and continue to invest in expanding this coverage. AWS-LC can be also built in FIPS mode to help consumers meet FIPS 140-3 compliance requirements. To give Ruby users a well-documented and supported way to take advantage of these investments, we would like to upstream build compatibility for AWS-LC into Ruby. We believe that this would provide the best experience for users wishing to build Ruby against AWS-LC. It would also allow users to circumvent maintaining and applying their own patch sets to build Ruby with AWS-LC. Earlier this year, weengaged with the CPython maintainers to successfully address similar needs for our respective users.

We are working on patch sets to integrate Ruby‘s OpenSSL module with AWS-LC. AWS-LC is committed to backwards compatibility and we aim to keep our API stable. Our open source repository has CI jobs (here and here) asserting every change’s compatibility with multiple different open-source projects. We’ve recently added Ruby 3.1 and 3.2 to this test suite and we’re in the midst of incorporating Ruby’s main branch and 3.3. These tests are used to catch compatibility regressions against every change before they’re merged and to resolve potential build issues beforehand when upstream projects make relevant changes. Relevant unit tests from the upstream projects’ are also ran to confirm that the underlying libcrypto & libssl behave as expected. By expanding our regular testing processes to include Ruby, we proactively prevent any unanticipated breaks in the Ruby/AWS-LC build.

The proposed integration supports all features of Ruby’s OpenSSL module, except for the use of DHE cipher suites in libssl. Excluding this, we have confirmed that all relevant unit tests for Ruby’s OpenSSL module perform as expected. If you folks agree that this integration would be beneficial for Ruby and its consumers, I’d be more than happy to put together a PR.

[samuel40791765]

I initially posted this in the general Ruby forum, but was directed here as the more appropriate communication channel for the Ruby openssl gem 😄.

[rhenium]

Yes, this GitHub repository is the upstream of the openssl stdlib in Ruby.

I had a quick look over the patch for Ruby 3.2: https://github.com/aws/aws-lc/blob/39b3fae26e2a17dc3808b30bc094cf113fcba7c7/tests/ci/integration/ruby_patch/ruby_3_2/aws-lc-ruby-temp.patch

Most of the changes look reasonable to me, and we'd be happy to review and incorporate your PRs.

A few random notes:

• Please add AWS-LC to our CI: https://github.com/ruby/openssl/blob/e5153dbbb4baa568b48bf2caf9af9b79dbfe2f1b/.github/workflows/test.yml
• Although it's already done for most, a mention of AWS-LC in non-obvious changes would be helpful, like test_verify_result and test_fallback_scsv in test_ssl.rb.
• OpenSSL::BN#to_s(16) (BN_bn2hex()) returning a lowercase String might break some programs. Should it be adjusted in the extension to match OpenSSL/LibreSSL behavior?

I have a question about the long-term maintenance plan of AWS-LC: from a quick glance at the aws/aws-lc repository, AWS-LC doesn't seem to have maintenance branches and releases are cut from the main branch currently. Does this mean that users are expected to always use the latest AWS-LC release?

Each Ruby release (including ruby/openssl) is generally maintained for 2.5 years for normal bugfixes (plus 1 year for security fixes)[*]. I think there can inevitably be some API-breaking changes in AWS-LC during the period, and some of them can affect ruby/openssl. In that case, should ruby/openssl maintain compatibility with the original AWS-LC release, or is compatibility with the latest release at that time sufficient?

[*] https://www.ruby-lang.org/en/downloads/branches/

[samuel40791765]

Thanks!! We’re more than happy to incorporate all the points you’ve provided. Regarding BN_bn2hex(), I’ve just submitted a modification here to align with OpenSSL/LibreSSL’s behavior as requested. We’ll strategically divide the patch into manageable segments and collaborate with you throughout the process. I imagine our initial focus will be targeting the master branch.

I have a question about the long-term maintenance plan of AWS-LC: from a quick glance at the aws/aws-lc repository, AWS-LC doesn’t seem to have maintenance branches and releases are cut from the main branch currently. Does this mean that users are expected to always use the latest AWS-LC release?

We maintain a rolling release model where users are encouraged to use the latest AWS-LC version. Each new release incorporates the most recent security patches, with the version numbers updated accordingly. For our FIPS releases, we maintain dedicated maintenance branches. These FIPS releases represent a past FIPS validated version of AWS-LC and we are committed to continuously cutting new FIPS releases and revalidating AWS-LC.
I would highlight that only the latest AWS-LC releases have proper support for Ruby at the moment. We’ve implemented significant changes to enhance Ruby compatibility only recently.

I think there can inevitably be some API-breaking changes in AWS-LC during the period, and some of them can affect ruby/openssl. In that case, should ruby/openssl maintain compatibility with the original AWS-LC release, or is compatibility with the latest release at that time sufficient?

Is there a strong preference you have for maintaining compatibility with the original or the latest? We'd normally recommend maintaining compatibility with the latest release as that has the latest critical security patches. AWS-LC prioritizes API stability, and we carefully avoid introducing breaking changes. We’re also dedicated to not breaking the tip of the master branch of the ruby/openssl gem. Our integration CI test suites help ensure that all changes we submit are tested against multiple versions of Ruby and the latest changes from ruby/openssl.

[rhenium]

I imagine our initial focus will be targeting the master branch.

Since this is a feature than a bugfix, it will go to the master branch and not backported. All Ruby users using Ruby 2.7 or later will still be able to use the latest openssl gem through RubyGems.

Is there a strong preference you have for maintaining compatibility with the original or the latest? We'd normally recommend maintaining compatibility with the latest release as that has the latest critical security patches.

Thanks for the clarification. That makes sense, and makes things simple. It doesn't seem worth it if older releases are not getting security fixes. I was wondering if checks around AWSLC_API_VERSION would be necessary in ruby/openssl in such an event.

[samuel40791765]

I was wondering if checks around AWSLC_API_VERSION would be necessary in ruby/openssl in such an event.

Checks around AWSLC_API_VERSION shouldn't be needed if we're keen on just maintaining compatibility with the latest AWS-LC releases.

A bit more context: This was mainly used by our upstream repo, BoringSSL, which follows a “live at head” model. This macro is less useful with the rolling release model AWS-LC has adopted.