Proposed changes

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. We would like to add AWS-LC support to nginx to provide our consumers with a well-documented and officially supported integration path. This would benefit both new users looking to leverage AWS-LC and existing users who already relying on our custom patch sets to use AWS-LC with nginx.

AWS-LC is a fork of BoringSSL which is already supported by nginx today. To enhance nginx compatibility, we’ve integrated key OpenSSL compatibility features including full OCSP support, multiple certificate slots, and HKDF consumption via EVP_PKEY. AWS-LC is also committed to backwards compatibility and we aim to keep our API stable. To ensure we continue to support nginx long term, we’ve added nginx built with AWS-LC to our integration CI. 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. By expanding our regular testing processes to include nginx, we proactively prevent any unanticipated breaks in the nginx/AWS-LC build.

I’ve noticed that there have been multiple attempts in the past to upstream AWS-LC support into nginx. We’ve made additional efforts to address concerns and minimize the necessary patch, but please feel free to let us know if you have any further feedback or concerns.

Best,
Samuel