-
Notifications
You must be signed in to change notification settings - Fork 237
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 #205
Conversation
Please include the language in the title for "L" proposals. Thanks! |
Sure, sounds good! |
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.
A few comments after quick look. Will do detailed review later today.
e580c31
to
59a25d1
Compare
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 let me know if you have any questions about any of this. Thanks!
L46-core-tls-credential-API.md
Outdated
|
||
## Abstract | ||
|
||
This proposal aims to enhance the security features provided by [this already implemented proposal](https://github.com/grpc/proposal/pull/98). |
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.
It looks like this proposal is designed to describe just the deltas relative to that earlier PR. However, that earlier PR was never approved or merged, which is why the existing TLS creds API is still marked experimental.
I have closed the earlier PR in favor of this one. This PR should be rewritten such that instead of referring to the earlier one, it completely replaces it. In other words, it should describe the entire TLS creds API, not just the recent changes.
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.
+1 Agree with Mark. Let's describe the entire TLS creds API.
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.
Sure. I revised this PR. Could you please take a look again? Thanks!
59a25d1
to
d7cb92b
Compare
3e80a61
to
2e257bd
Compare
L46-core-tls-credential-API.md
Outdated
- perform both the certificate and default hostname check(default option) | ||
- perform certificate check but skip default hostname check(a custom authorization check is mandatory) | ||
- skip both certificate check and default hostname check(a custom authorization check is mandatory) | ||
- perform a custom authorization check, if needed |
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.
It is a little confusing to have custom authorization check
in both title and bullet items (client and server side).
Also since this gRFC does not propose any API to specify the first three cases (of client-side), it does not make much sense to explain them in details (sorry for the previous comment). WDYT?
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.
Yeah, Jiangtao and Mark wanted to me write a full introduction about the TLS credential to be a replacement of our previous gRFC, so I am trying to include the all features here, no matter whether it is already implemented or not.
I do agree the current abstract contains more information than needed. Revised. Please take a look, thanks!
*/ | ||
GRPCAPI int grpc_tls_credentials_options_set_server_verification_option( | ||
grpc_tls_credentials_options* options, | ||
grpc_tls_server_verification_option server_verification_option); |
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.
Do you plan to introduce grpc_tls_client_verification_option
enum for the client-side custom authorization check?
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 can do either way. Having a grpc_tls_client_verification_option
is what we are doing in Go.
If server side doesn't want to verify the certificate, it can choose the corresponding GRPC_SSL_REQUEST_AND_REQUIRE_CLIENT_CERTIFICATE_BUT_DONT_VERIFY
value in grpc_ssl_client_certificate_request_type
, which I think is equivalent here. But I am also fine adding a grpc_tls_client_verification_option
to make it (probably) easier for users to understand, etc.
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.
+1 on having grpc_tls_client_verification_option
for extendability.
std::map<std::string /*cert_name*/, CertsWatching> certs_watching_; | ||
}; | ||
``` | ||
### Custom Authorization |
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.
@jiangtaoli2016 What's the plan for supporting async authorization check? The current server authorization check supports both sync and async, which is pretty complicated due to async support and goes against the goal of simple C-core API. The API's in this section can be simplified a lot if we decide to only support sync authorization check.
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 async authz check has its values, especially considering the fact that a check can take a long time and we don't want to block the main thread.
I was thinking for a long time if we can make grpc_tls_authorization_check_arg
a class instead of a struct? Currently it contains a lot of information that the caller(from the wrap languages) doesn't need to know. That may simplify the logic a little bit, but I am not sure how long the refactoring would take...
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.
If we decide to support async, we first need to flush out some details on how to wrap the C-core API's related to server authorization check (e.g., grpc_tls_authorization_check_arg
and others).
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.
OK. How about me writing a one pager briefly describe the necessary changes this would take?
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.
Yeah, but it also needs to be signed off by TL's of each wrapped language, which may take longer than we expect. Do we have an immediate use case for async authorization check @jiangtaoli2016? If we do not, how about we start with a simple sync version in this gRFC and introduce an async version in another gRFC when its design is mature?
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.
We need to support async authz check, e.g., if customer needs to validate the cert chain with a remote server or fetching server authz ACLs remotely. gRPC core cannot be blocked. This is a requirement from @markdroth .
Yihua: we can re-use your previous server authorization check cb API, which was reviewed by Mark. Any concern with it?
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.
At the time I worked on async server authz check, I did not consider much about whether it can be easily wrapped by languages other than C++, while gRFC aims for the API simplicity for ALL wrapped languages. I am not sure if struct
and function pointer fields in grpc_tls_authorization_check_arg
can be easily wrapped.
Hi, this looks great, however we were wondering if this can also support TLS-PSK (Pre-Shared Keys)? For TLS 1.3 the TLS-PSK mode enables 0-RTT handshakes, reducing overhead for resource constrained use-cases |
No, I don't think so. This API is mainly for "common" TLS with asymmetric keys. |
Proposal - grpc library to provide support to configure TLS version at run time? Such that application can opt TLS version (1.2 or 1.3) at run time. Basically user can configure TLS version to use. |
This proposal has APIs for setting TLS version and JFYI I have grpc/grpc#31368 pending review for this. |
No description provided.