Add support for BoringSSL as an alternative to OpenSSL

h2o / picotls

TLS 1.3 implementation in C (master supports RFC8446 as well as draft-26, -27, -28)

536 stars 140 forks source link

Add support for BoringSSL as an alternative to OpenSSL #432

Closed jedisct1 closed 1 year ago

jedisct1 commented 1 year ago

When using BoringSSL:

X25519 key exchange uses the dedicated X25519 API in order for the scalar to be properly clamped.
AEADs use the dedicated AEAD API. New ciphers such as ChaChaPoly are not available when using the old API.
Blowfish has been deprecated and was removed from libcrypto; linking the decrepit library is required.
BoringSSL doesn't come with a pkgconfig file, so defining BORINGSSL_ROOT_DIR is required.

fluffy commented 1 year ago

If I only want to use AES-128-GCM-SHA256, could this PR easily be made to work for just that ?

suhasHere commented 1 year ago

@kazuho @jedisct1 May i know the plan for moving forward with this PR. We are using picotls (along with picoquic) and often seeing a need to move to boringssl. This work will greatly benefit.

Also agree wth @fluffy and love to get your thoughts on moving boringssl incrementally if it helps lands the base work.

Please let me know.

kazuho commented 1 year ago

@jedisct1 Thoughts?

@fluffy

If I only want to use AES-128-GCM-SHA256, could this PR easily be made to work for just that ?

I'm not sure... libcrypto provides all the cryptos as one library. This PR swaps that library to the one provided by boring.

jedisct1 commented 1 year ago

This PR allows using BoringSSL as an alternative to OpenSSL. The picotls API is unchanged. All the tests are passing, as well as a large part of an application we're working on internally.

Support for Chacha20 and X25519 can be removed, and get eventually reintroduced in a different PR.

I originally used specific callbacks and dedicated structures just for these primitives, but the resulting code ended up being more convoluted, and eventually less maintainable.

kazuho commented 1 year ago

@jedisct1 :+1:

Support for Chacha20 and X25519 can be removed, and get eventually reintroduced in a different PR.

I think we can possibly do that for Chacha but maybe not for X25519, considering it is the de-facto standard key exchange algorithm being used? We can fall back to p256 at a performance penalty but...

huitema commented 1 year ago

The CI tests are failing. I think there are several issues:

1- Maybe some missing commits. Merge main branch into this PR would fix that 2- Missing a specific test for BoringSSL, on the model of macOS/libreSSL, so we track regressions in Boring support 3- CMake error in Linux builds should be fixed:

 CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
BORINGSSL_DECREPIT_LIBRARY (ADVANCED)
    linked by target "picotls-openssl" in directory /picotls
    linked by target "picotls-esni" in directory /picotls
    linked by target "test-openssl.t" in directory /picotls
    linked by target "ptlsbench" in directory /picotls