Exposing peer client certificate within server calls (ie, as a context or metadata)

[davidfiala]

I'm curious what the current mood is towards exposing TLS peer certificate in a way that allows a gRPC server to know it's client/peer's TLS certificate. gRPC clients currently have a callback which includes the server cert thanks to #1968 so this discussion here is purely for a server to know its client's identity.

Related discussion here: grpc/grpc#7834 I think @jboeuf may have thoughts he could share. Maybe an updated 2024 version :)

Within Google, gRPC peer identities are exposed and mutual auth depends on that being possible. Externally, I haven't seen an obvious solution within grpc-js, although IIRC other gRPC language libraries might(??) expose it. I could be remembering wrong.

I believe that grpc-js ought to make granular access via peer identities a recommended approach. Google couldn't operate without it, so why wouldn't we make this available to the world, too?

FWIW: I also don't see a way to write a middleware outside of the grpc-js library that could extract and make available the TLS Certificate of a peer. I personally rely on using a modified grpc-js library which does extract and expose this information and make it available in places like a call context or metadata. But my use is thus non-standard. And I know others are interested. (ie, an unanswered post from 2020: #1258) but I'm certain I've read plenty more requests on the internet.

So, any thoughts? What's holding us back from exposing the client's TLS Cert from existing as part of a call context or injected metadata header? (obviously, security concerns should be addresses for protecting such a metadata header)

Thanks for your time and thoughts.

[murgatroid99]

gRFC L35 proposes an API to expose this information to the application. PR #508 would have implemented it in the old Node gRPC library, but clearly it was never resolved. The implementation work for grpc-js just never happened.

That gRFC has a relatively restricted API because of constraints that no longer apply, namely needing to handle the intersection of the two libraries. At this point, that proposal could probably be modified to be more expressive in grpc-js in ways that are incompatible with the old library.

[davidfiala]

Thanks for the note. Seems like there is agreement that something should exist. :)

At the risk of sidetracking, but since it wasn't implemented yet: I'd ask whether we there's openness also to reconsider the implementation regarding passing raw cert buffers around. My thought is that for a server under load it wouldn't be ideal to decode the same cert multiple times per call or risk double copies of Buffers if that were to end up happening. Exposing the Http2Session or it's net.Socket | net.TLSSocket directly could allow for further flexibility for the developer to have useful information even on non-TLS connections. My big ask though is simply to have a performant way to get at the data, without being too prescriptive.

WDYT?

[murgatroid99]

That's why I meant by modifying the proposal to make the API more expressive. For example, it could contain the full output of tlsSocket.getPeerCertificate, instead of just the raw cert. As I said, that limitation was the result of previous constraints that no longer apply.

[davidfiala]

Hi- I put together some thoughts here: grpc/proposal#440