-
Notifications
You must be signed in to change notification settings - Fork 228
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
L46: C-core: New TLS Credentials API #422
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a rework of the cert provider section, still need to address the verification side
~TlsCustomVerificationCheckRequest() {} | ||
|
||
absl::string_view target_name() const; | ||
absl::string_view peer_cert() const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that comment is another signal that this API is not useful for anyone since they cannot really predict what the return value should be. I think we should probably deprecate + delete this API and replace it with APIs that return predictable and explicit values.
// Sets the certificate verifier. The certificate verifier performs checks on | ||
// the peer certificate chain after the chain has been (cryptographically) | ||
// verified to chain up to a trusted root. | ||
// If unset, this will default to the `HostNameCertificateVerifier` detailed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it only do this default on the client-side?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good question - I think it depends on other defaults, and if we are doing MTLS vs. TLS? I'll double check, but I don't believe this is called unless it is configured to do MTLS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that's correct. For example, we want it to default to the HostnameVerifier on the client-side even when we are doing (normal) TLS only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant on client side it would default to HostNameCertificateVerifier
, but it wouldn't on the server side if we are only doing TLS, not mTLS?
This relates to that other comment, I need to draw out the links with the OpenSSL stack to see what of the custom verification is happening if we aren't doing verification
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default (e.g. that SSL credentials and most TLS libraries have) should be:
- The client always does the hostname check.
- The server never does the hostname check, regardless of whether a client cert was requested or not.
Indeed, there is no meaningful "hostname check" that a server can perform on a client cert (e.g. what string is the server looking for in the client cert?).
L46-core-tls-credential-API.md
Outdated
// identity certificates(single side TLS). | ||
class TlsChannelCredentialsOptions final : public TlsCredentialsOptions { | ||
public: | ||
// Sets the decision of whether to do a crypto check on the server certs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Despite the other comment, I think we need to clean up this comment so that it is more precise. :)
~TlsCustomVerificationCheckRequest() {} | ||
|
||
absl::string_view target_name() const; | ||
absl::string_view peer_cert() const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we get a verified chain on resumed handshakes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, modulo the newly-added comments.
// Sets the certificate verifier. The certificate verifier performs checks on | ||
// the peer certificate chain after the chain has been (cryptographically) | ||
// verified to chain up to a trusted root. | ||
// If unset, this will default to the `HostNameCertificateVerifier` detailed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that's correct. For example, we want it to default to the HostnameVerifier on the client-side even when we are doing (normal) TLS only.
~TlsCustomVerificationCheckRequest() {} | ||
|
||
absl::string_view target_name() const; | ||
absl::string_view peer_cert() const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya that's what I was hinting at. Resumed handshakes skip the cryptographic verification, but I'm not sure if they skip the post-handshake verification. If that's correct, we need to explain that some of these fields may not be available on resumed handshakes.
// identity credentials will be used. | ||
class TlsChannelCredentialsBuilder final : public TlsCredentialsBuilder { | ||
public: | ||
// Sets the decision of whether to do a crypto check on the server certificates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also add the "WARNING" comment to this API.
This PR is subsuming the previous PR of the same title (#205), and attempting to bring the content to the current state with the goal of formally merging this and moving these API from experimental to stable.
This is still under active work and is not ready for final review.