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

grpc_ssl_client_certificate_request_type doc comments are not very understandable #15588

Closed
jtattermusch opened this issue May 31, 2018 · 3 comments
Closed

Comments

@jtattermusch
Copy link
Contributor

@jtattermusch jtattermusch commented May 31, 2018

I'm trying to add C# support for grpc_ssl_client_certificate_request_type options, but I'm struggling to understand the actual meaning of the grpc_ssl_client_certificate_request_type enum values. Can we improve them? Having a good understanding of these enums is critical as we cannot afford misunderstandings when it comes to security.

/** Server does not request client certificate. A client can present a self
signed or signed certificates if it wishes to do so and they would be
accepted. */
GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE,
/** Server requests client certificate but does not enforce that the client
presents a certificate.
If the client presents a certificate, the client authentication is left to
the application based on the metadata like certificate etc.
The key cert pair should still be valid for the SSL connection to be
established. */
GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY,
/** Server requests client certificate but does not enforce that the client
presents a certificate.
If the client presents a certificate, the client authentication is done by
grpc framework (The client needs to either present a signed cert or skip no
certificate for a successful connection).
The key cert pair should still be valid for the SSL connection to be
established. */
GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_AND_VERIFY,
/** Server requests client certificate but enforces that the client presents a
certificate.
If the client presents a certificate, the client authentication is left to
the application based on the metadata like certificate etc.
The key cert pair should still be valid for the SSL connection to be
established. */
GRPC_SSL_REQUEST_AND_REQUIRE_CLIENT_CERTIFICATE_BUT_DONT_VERIFY,
/** Server requests client certificate but enforces that the client presents a
certificate.
The cerificate presented by the client is verified by grpc framework (The
client needs to present signed certs for a successful connection).
The key cert pair should still be valid for the SSL connection to be
established. */
GRPC_SSL_REQUEST_AND_REQUIRE_CLIENT_CERTIFICATE_AND_VERIFY

Things that are not clear to me:

  • what's the difference between GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE and GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY? Based on the description they look like they are doing the same thing?
  • what does it mean if "client authentication done by grpc framework". What is checked against what? When is the connection accepted/rejected?
  • what is the distinction between "authenticate" and "verify" a certificate. I'm not sure what the "*_AND_VERIFY" options actually do. Basically I don't fully understand the concepts of "don't request"/ "request"/ "require" / "verify".
  • What exactly does it mean "The key cert pair should still be valid for the SSL connection to be established"?
  • what does "skip no certificate" mean here:
    grpc framework (The client needs to either present a signed cert or skip no
    Is that a typo?
  • if authentication is left to the application, what do I need to do? what API do I use? (see
    the application based on the metadata like certificate etc.
    )
@jtattermusch

This comment has been minimized.

Copy link
Contributor Author

@jtattermusch jtattermusch commented May 31, 2018

@jtattermusch

This comment has been minimized.

Copy link
Contributor Author

@jtattermusch jtattermusch commented May 31, 2018

FTR the options have been added in #5958

@deepaklukose

This comment has been minimized.

Copy link
Contributor

@deepaklukose deepaklukose commented Aug 16, 2018

Most of the options are relevant only when you are dealing with self-signed certificates. These options essentially give a way to deal with self signed certificates in multiple ways.

There are multiple factors at play here:
a. Did the server request a client certificate during ssl handshake
b. Did the client present a client certificate (irrespective of whether the server asked for it)
- If the client presented a certificate was the certificate self signed by the client or if the signature can be verified using the ssl protocol.
c. Is the signature verification done by ssl protocol or independently by the app (for self signed certificates for example by inspecting the certificate hash or other information in metadata).

Mapping from these option to ssl options

  1. With GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE: Server does not request for a client certificate. So the client can choose to present a self-signed or a signed certificate or not present a certificate at all and all of these should be okay.
    With GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY: Server requests the client for a certificate but the signature enforcement is not done by grpc server framework but left to the app. The app can use metadata like the certificate hash to verify a certificate (essentially provides the server a
    way to verify self signed certificates, provided they have an out of band mechanism to register the certificate with the app)
  2. By "client authentication done by grpc framework", I meant certificate signature verification is done using the ssl protocol itself by the grpc server framework (SSL_VERIFY_PEER option is being used in ssl options). The client has to provide a signed certificate which can be verified by the server (using the SSL roots file).
  3. "don't request"/ "request"/ "require" / "verify"
    - Server has the option to either request or not-request for client cert.
    - Client can choose to either present a certificate or not.
    - Server can choose to verify the client certificate or not
    Each of these three options are independent of each other and contribute to multiple options presented.
    "require" for instance is the case server request for client cert, client has to present a certificate for the ssl handshake to continue but the server will not verify the client certificate using signature but can do so if needed based on certificate metadata.
    "verify" - SSL_VERIFY_PEER option is being used in ssl options and the client signature is verified/trusted by the server using the SSL roots file.
  4. All of the above pretty much expected that the private key and the public key files were all in okay and the only question was whether they were self signed or signed by a mutually trusted CA. If the public key and private keys don't match up then the connection fails.
  5. It is a typo. It should have been "The client needs to either present a signed cert or not present a
    certificate at all for a successful connection"
  6. grpc_auth_context has various properties of the peer like GRPC_X509_CN_PROPERTY_NAME, GRPC_X509_PEM_CERT_PROPERTY_NAME, GRPC_X509_SAN_PROPERTY_NAME that can be used.

@jtattermusch Hope this helps!

@lock lock bot locked as resolved and limited conversation to collaborators Nov 28, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.