[tls] Add an extension point for TLS handshaker behavior.#12658
[tls] Add an extension point for TLS handshaker behavior.#12658lizan merged 35 commits intoenvoyproxy:masterfrom
Conversation
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
726ed24 to
ae2dd4e
Compare
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
…shaker Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
PiotrSikora
left a comment
There was a problem hiding this comment.
I think a lot more configuration settings should be guarded, since depending on what's handled by the custom handshaker, a lot of features in the context is going to be a dead code:
- Does the custom handshaker provide certificates and/or private key operations?
- Does the custom handshaker handle session resumption (Session IDs, Session Tickets, PSK)? Notably, in TLS 1.3,
NewSessionTicketmessage is sent after the handshake is completed. - Does the custom handshaker handle ALPN negotiation?
- Does the custom handshaker verify client certificates?
- Is the custom handshaker FIPS compliant? Should we reject configuration if non-compliant handshaker is provided in
--define=boringssl=fipsbuilds?
…shaker Signed-off-by: James Buckland <jbuckland@google.com>
…erContextConfigImpl. Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
…n Envoy Signed-off-by: James Buckland <jbuckland@google.com>
This makes sense to me. I've introduced a struct enumerating these requirements ( |
Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
…shaker Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
|
/retest |
|
Retrying Azure Pipelines, to retry CircleCI checks, use |
|
/retest |
|
Retrying Azure Pipelines, to retry CircleCI checks, use |
|
@PiotrSikora PTAL. Any other comments? |
|
/retest |
|
Retrying Azure Pipelines, to retry CircleCI checks, use |
There was a problem hiding this comment.
You need to go through all code of TLS extension and add capability guards where appropriate, e.g. the certificate loading block is not guarded by capabilities right now, etc.
Also, it would be helpful if you were consistent and always added them either as the first or as the last condition, right now it's mixed.
…shaker Signed-off-by: James Buckland <jbuckland@google.com>
Signed-off-by: James Buckland <jbuckland@google.com>
The capability guards are now either outside, or the last argument to a conditional. I added some capability guards around the cert loading mechanisms as well. Thanks for catching this :) |
|
/retest |
|
Retrying Azure Pipelines, to retry CircleCI checks, use |
|
/retest |
|
Retrying Azure Pipelines, to retry CircleCI checks, use |
|
@ambuc post merge drive by: can you please add a release note and some documentation for this feature? For docs I'm thinking here? https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl In particular it would be good to briefly discuss how this feature is different from the existing private key methods support. Thank you! |
| info_ = std::make_shared<SslHandshakerImpl>(std::move(ssl), ctx_, this); | ||
|
|
||
| ctx_(std::dynamic_pointer_cast<ContextImpl>(ctx)), | ||
| info_(std::dynamic_pointer_cast<SslHandshakerImpl>( |
There was a problem hiding this comment.
I'm probably missing something, but how is this dynamic_cast safe if someone is using a custom implementation? Don't you need a virtual method to get the info off of the handshake interface since you don't know the inheritance structure of the implementation?
There was a problem hiding this comment.
My custom implementation in the test is fortunate enough to extend SslHandshakerImpl. My thought was that anyone who wanted to write their own custom implementation of Ssl::Handshaker would also want to extend the existing SslHandshakerImpl to avoid reimplementing all the fiddly methods in ConnectionInfo. But you're right, this isn't safe for anyone who writes their own impl which doesn't extend SslHandshakerImpl.
I think the right thing to do here is (a) add the relevant methods to Ssl::Handshaker (the interface) so that it's OK for (b) info_ to be an Ssl::Handshaker*. I'll fix this forward in a new PR.
There was a problem hiding this comment.
Cool thanks. Feel free to combine with the docs PR. Up to you.
There was a problem hiding this comment.
Addressing this in #13081. Docs PR to follow.
Addressing this in #13083. |
Commit Message: Add an extension point to allow overriding TLS handshaker behavior.
Additional Description: This PR necessitated decoupling SslHandshakerImpl from ContextConfig a bit. We now pass an int representing the index of the extended_info struct rather than the ContextConfig.
This PR moves SslHandshakerImpl to its own build target, moves SslHandshaker construction into the ContextConfig, and adds a HandshakerFactoryContext and HandshakerFactory for modifying the ContextConfig's behavior when constructing a Handshaker. This PR also adds a control (requireCertificates) to turn off the release asserts that a context must have certificates.
This PR builds off work in #12571 and refines work done (and abandoned) in #12075. For more discussion please see the comments section of #12075.
Risk Level: Low. This PR does not modify existing handshaking behavior, it just adds an extension point for modifying it.
Testing: A representative alternative implementation was added under :handshaker_test.
Docs Changes: N/a
Release Notes: N/a