API to add constraints on SSL for key size

Is your feature request related to a problem? Please describe.

I have a gRPC server which is using mutual TLS and I want to reject connections from clients who have a public key size less than 2048 bits.

Describe the solution you’d like

There should be an API in the SslContextBuilder class to set SSL key size related constraints

Describe alternatives you’ve considered

I was able to achieve the same using a ServerInterceptor by doing something like this

public class SSLInterceptor implements ServerInterceptor {
    @Override
    public <ReqT, RespT> Listener<ReqT> interceptCall(ServerCall<ReqT, RespT> call, Metadata headers, ServerCallHandler<ReqT, RespT> next) {
        try {
            SSLSession sslSession = call.getAttributes().get(Grpc.TRANSPORT_ATTR_SSL_SESSION);
            RSAPublicKeyImpl pk = (RSAPublicKeyImpl) sslSession.getPeerCertificates()[0].getPublicKey();
            if (pk.getModulus().bitLength() < 2048) {
                // reject call
            }
            // proceed with the call
        } catch (SSLPeerUnverifiedException e) {
            // do something
        }
        ...
    }
}

This is a bad way to do it because

1. The validation is being done after the connection is already established.
2. The validation is only triggered when a request/call is made.
3. Every single call involves an extra overhead of validation.
4. In case of a validation failure, only the call is rejected but not the connection to the client.

In an ideal scenario

1. The validation is done during the connection establishment phase. (or some point during the creation of the channel between client and server)
2. The validation failure would prevent the connection from being created and not set it up and disconnect later.
3. A client is only validated once per session and all the calls made during that session do not incur any overhead.

[ejona86]

@adityavikasd, I’d suggest making your own TrustManagerFactory. It seems you could extend TrustManagerFactory and override all the methods, delegating to another instance, except for getTrustManagers() in which you would write custom logic to return your trust manager instead of the default one.

The other potential option is to implement TrustManagerFactorySpi. You will still need to delegate to a real instance, so maybe create one with something like (TrustManagerFactorySpi) Security.getProvider("JSSE").getService("TrustManagerFactory", TrustManagerFactory.getDefaultAlgorithm()).newInstance(null). I’d probably start with providing the “real” Provider to the TrustManagerFactorySpi.

I’ve never done any of that before, but they seem like avenues try. I realize that the Java API is quite opaque, but it’s also all we have.

[adityavikasd]

Thanks for the help. I was able to implement this. By creating my own TrustManagerFactorySp, TrustManagerFactorySpi and TrustManager.

The Java security API seem so twisted though!