Support for building with AWS Libcrypto (AWS-LC)

[skmcgrail]

Hello,

I'm an engineer at AWS working on AWS-LC, AWS's open-source fork of Google's BoringSSL. We would like to propose adding AWS-LC support to netty-tcnative, alongside its existing support for OpenSSL, BoringSSL, and LibreSSL.

AWS-LC shares a similar API surface area to the existing BoringSSL integration within your library, while providing additional benefits for users.
We are committed to backwards compatibility and maintain extensive CI testing infrastructure that continuously validates compatibility with many open-source projects.
We plan to add netty-tcnative compatibility testing to this suite to ensure ongoing compatibility.

Some of the highlights offered by this integration:

1. Performance optimizations specifically targeted for modern CPU architectures, including AWS Graviton processors, and Intel x86-64 with AVX-512 instructions
2. Formal verification of critical cryptographic primitives, with ongoing investment in expanding verification coverage.
3. FIPS 140-3 compliance support through a dedicated FIPS build mode.

Given netty-tcnative's existing support for BoringSSL, integrating AWS-LC is relatively straightforward.
This integration would provide netty users with a well-supported path to leverage AWS-LC's improvements in performance, security,
and compliance without requiring them to maintain custom patches or modifications.

The this integration supports all current netty-tcnative functionality that is supported for the BoringSSL integration.

Currently this pull request targets users who build the netty-tcnative JARs themselves following the How to build instructions. This would allow users wanting to use AWS-LC to do so successfully.

At this time I don't see an explicit need to offer static compilations of AWS-LC bundled in a jar file (similar to the BoringSSL integration). I noticed
that the current LibreSSL static build is not published, so I wasn't sure if maintaining these static variants is a goal in the long-term, but would be open
to discuss further if you'd like.

Once this PR is merged in I can publish the corresponding PR to netty to make necessary adjustments there for the netty-tcnative with aws-lc integration to work as expected and have additional testing as necessary.

[chrisvest]

I think this is interesting, at as a weak build-it-yourself offering.

Long-term our focus is with BoringSSL. We're constrained by the compatibility requirements of Netty in terms of timeline, but I think we'd like to drop OpenSSL and LibreSSL for Netty 5. AWS-LC is more interesting, IMO, because of the features you highlight.

How closely are you tracking BoringSSL? We occasionally find (and sometimes fix) issues in BoringSSL, so we like our ability to quickly integrate the latest version.

[chrisvest]

(code scanning build failures look like they're caused by the maven central migration)

[skmcgrail]

How closely are you tracking BoringSSL? We occasionally find (and sometimes fix) issues in BoringSSL, so we like our ability to quickly integrate the latest version.

Where it stands today for netty-tcnative (netty proceeding after this pull request) is that there is very minimal differences between BoringSSL and AWS-LC. I would say strategically though the two projects are slowly drifting apart. In part this is due AWS-LC focusing on providing a migration path for users who today target OpenSSL 1.1.1 and are evaluating their options whether to migrate to OpenSSL 3.x or seek potential alternatives with alternative performance profiles. Thus we have been focused on re-introducing features or APIs that may have been previously removed from BoringSSL in order to assist in being compatible with OpenSSL, providing the benefits outlined previously, and focusing on targeting long-term support for the APIs.

An example difference between AWS-LC and BoringSSL, that is applicable to this integration is ciphersuite handling in the SSL APIs. The BoringSSL APIs do not allow for explicit configuration of the TLS 1.3 ciphersuites, and when querying the configured ciphersuites (in preference oder) using SSL_get_ciphers / SSL_CTX_get_ciphers those only return the TLS 1.2 or lower ciphersuites. This differs from OpenSSL and AWS-LC which do allow configuration of the TLS 1.3 ciphersuites, and that do return the TLS 1.3 and lower ciphersuites when calling the associated getter functions.

[normanmaurer]

@skmcgrail this sounds interesting... gimme a few days to review this in more detail

[skmcgrail]

Hey @normanmaurer was just curious if you had gotten any chance to consider this change any further? Thanks!

[normanmaurer]

@skmcgrail sorry didn't have time yet... That said I am currently don't see a reason why we couldn't include your changes.

Did you sign our icla yet ? https://netty.io/s/icla

[normanmaurer]

This looks good to me... That said I am not sure if we are ready to also release these artifacts (the same as we don't release openssl-static and libressl-static)

[skmcgrail]

This looks good to me... That said I am not sure if we are ready to also release these artifacts (the same as we don't release openssl-static and libressl-static)

For the moment I think we are content with this as only being a build-it-yourself option, which should allow this to get merged. We can always have a follow-up discussion if we want to explore offering these as distinct jars like boringssl, libressl, and openssl-static. Getting this merged in would unblock being able to stage a subsequent PR to netty itself for updates for that to work with these changes to support AWS-LC.

[normanmaurer]

@skmcgrail thats fair enough… Thanks for the contribution, I just merged the PR