GrpcSslContext bug for mutual authentication

[megapowers]

Hi,

My 1-way SSL authentication is working with the codes below, however, it doesn't seem to work for 2-way. I understand that by declaring the appropriate SslContext, we should be able to enable mutual authentication. I have already invoked the appropriate keyManager/trustManager, any idea why the mutual authentication did not take place?

I followed the steps to set up jetty ALPN at https://github.com/grpc/grpc-java/blob/master/SECURITY.md.

---

@ Server:

SslContext sslContext = GrpcSslContexts.forServer(new File(pathToOwnCertPemFile), new File(pathToOwnPrivateKeyPemFile)).trustManager(new File(pathToClientCertPemFile)).build();

ServerImpl server = NettyServerBuilder
        .forPort(port)
        .sslContext(sslContext)
        .addService(MyGrpc.bindService(new MyGrpcService()))
        .build().start();

---

@ Client:

SslContext sslContext = GrpcSslContexts.forClient().trustManager(new File(pathToServerCertPemFile)).keyManager(new File(pathToOwnCertPemFile), new File(pathToOwnPrivateKeyPemFile)).build();

ChannelImpl channel = NettyChannelBuilder.forAddress(host, port)
                .negotiationType(NegotiationType.TLS)
                .sslContext(sslContext).build();

blockingStub = MyGrpc.newBlockingStub(channel);

---

Upon inspection of the SSL debug logs, I noticed that the CertificateRequest message (as stated in https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake), was never sent to the client to initiate the Client Authentication.

An excerpt of my server log is as follows:

*** ECDH ServerKeyExchange
Signature Algorithm SHA512withRSA
Server key: Sun EC public key, 256 bits
public x coord: 81392923578261760187813715443713168545877454618233337093852615933913992434989
public y coord: 26389586381130695169212775668808794166799180199461581135201001980310825571555
parameters: secp256r1 NIST P-256, X9.62 prime256v1
*** ServerHelloDone
[write] MD5 and SHA1 hashes: len = 1617
0000: 02 00 00 56 03 03 55 DF 34 10 9C 73 B5 00 C2 70 ...V..U.4..s...p
0010: FD B8 CC 36 5B 83 87 70 5B 74 A3 D2 AD B7 75 3B ...6[..p[t....u;

Am I missing out something? Or is it an inherent bug in gRPC?

Appreciate any advice on this problem.

[ejona86]

It does seem it is a current limitation, either due to Netty or gRPC. What is missing is a call to SSLEngine.wantClientAuth(true). It's not clear whether Netty's SSLContext should support setting that or whether gRPC should have the option on the builder.

[megapowers]

Will the implementation of the missing call to SSLEngine.wantClientAuth(true) be in the pipeline?

[ejona86]

I'm not quite sure yet where we will put it. I would probably favor adding the configuration to Netty's SslContextBuilder, but it will take some investigation.

If you want to hack up a change for your local usage, you can add the line to NettyServerTransport or ProtocolNegotiators.

[ejona86]

Support from Netty for requesting client certificates was added in netty/netty#4237

[ejona86]

Closing since it seems necessary features are now available in netty.

[matthild]

A word of warning: It appears that in some environments the GRPC server accepts untrusted client certificates.