Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for BoringSSL asynchronous private key operations #6248

Closed
ipuustin opened this issue Mar 11, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@ipuustin
Copy link
Member

commented Mar 11, 2019

Title: Support for BoringSSL asynchronous private key operations

Description:
BoringSSL has support for asynchronous private key operations [1]. The operations can be used for TLS signing and decryption. It would be nice to have Envoy support the asynchronous operations by implementing an private key extension API. An extension implementing the API could be registered for a TLS context. There has been discussion regarding this at envoy-dev mailing list, and I think this is the preferred approach.

My use case for this functionality would be TLS hardware acceleration (using Intel QuickAssist Technology), but other use cases exist, such as having keys in separate hardware or network service.

I would like to have a try at implementing this, if this is something that might be of interest. I'm opening this issue for suggestions and comments before going for the implementation. :-) My current prototype of the BoringSSL private key support in Envoy suggests that at least the following functionality is needed:

  1. In the new API, have a function for finding out if the current TLS context should be handled asynchronously or not (call the extension with TL parameters). For example, not all ciphers can be accelerated.
  2. Create a ssl_socket.cc callback to make it possible to call TLS functions (SSL_do_handshake()) again when the async operation has finished in the extension.
  3. Add plumbing to let the private key extension to add callbacks to the thread event loop.

Relevant Links:
[1]: https://github.com/google/boringssl/blob/master/PORTING.md#asynchronous-and-opaque-private-keys

CC @PiotrSikora @htuch

@htuch htuch added the enhancement label Mar 11, 2019

@htuch

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

@ipuustin thanks, this is well aligned with how we had envisaged this working, please go ahead. Can you propose a concrete API PR (even as WiP) so we can make sure we are aligned before going too far? I'm personally interested in making use of BoringSSL split handshake in the near future, but this is somewhat different to private key operations.

@stale

This comment has been minimized.

Copy link

commented Apr 10, 2019

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 10, 2019

@stale

This comment has been minimized.

Copy link

commented Apr 17, 2019

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

@stale stale bot closed this Apr 17, 2019

@htuch htuch added no stalebot and removed stale labels Apr 17, 2019

@htuch htuch assigned htuch and ipuustin and unassigned htuch Apr 17, 2019

@yangminzhu

This comment has been minimized.

Copy link
Contributor

commented May 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.