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

L46: C-core: New TLS Credentials API #205

Closed
wants to merge 20 commits into from

Conversation

ZhenLian
Copy link

@ZhenLian ZhenLian commented Sep 8, 2020

No description provided.

@dfawley
Copy link
Member

dfawley commented Sep 8, 2020

Please include the language in the title for "L" proposals. Thanks!

@ZhenLian ZhenLian changed the title L46: Update the TLS Credential API to Support More Use Cases L46: Update the TLS Credential API to Support More Use Cases in C Core Sep 8, 2020
@ZhenLian ZhenLian changed the title L46: Update the TLS Credential API to Support More Use Cases in C Core L46: Update the TLS Credential API in C Core to Support More Use Cases Sep 8, 2020
@ZhenLian
Copy link
Author

ZhenLian commented Sep 8, 2020

Please include the language in the title for "L" proposals. Thanks!

Sure, sounds good!

Copy link
Contributor

@jiangtaoli2016 jiangtaoli2016 left a 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.

L46-core-tls-credential-API.md Outdated Show resolved Hide resolved
L46-core-tls-credential-API.md Outdated Show resolved Hide resolved
L46-core-tls-credential-API.md Outdated Show resolved Hide resolved
L46-core-tls-credential-API.md Outdated Show resolved Hide resolved
@markdroth markdroth changed the title L46: Update the TLS Credential API in C Core to Support More Use Cases L46: C-core: New TLS Credentials API Sep 8, 2020
Copy link
Member

@markdroth markdroth left a 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 Show resolved Hide resolved

## Abstract

This proposal aims to enhance the security features provided by [this already implemented proposal](https://github.com/grpc/proposal/pull/98).
Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Author

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!

L46-core-tls-credential-API.md Outdated Show resolved Hide resolved
- 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
Copy link
Contributor

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?

Copy link
Author

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);
Copy link
Contributor

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?

Copy link
Author

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.

Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Author

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...

Copy link
Contributor

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).

Copy link
Author

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?

Copy link
Contributor

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?

Copy link
Contributor

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?

Copy link
Contributor

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.

@jtattermusch
Copy link
Contributor

CC @jtattermusch

@7hacker
Copy link

7hacker commented Oct 7, 2020

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

@ZhenLian
Copy link
Author

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.

@mankhakb
Copy link

mankhakb commented Mar 6, 2023

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.

@rockspore
Copy link
Contributor

This proposal has APIs for setting TLS version and JFYI I have grpc/grpc#31368 pending review for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.