HostnameVerifier exists in OkHttpChannelBuilder, but not exists in NettyChannelBuilder

[becomeStar]

Hello. I have a question about hostname verification using ssl protocol in grpc-java.
In test environment, I needed to use InsecureTrustManagerFactory.INSTANCE
when building ManagedChannel to avoid certification verification.
When I use nettyChannelBuilder in client side, hostname check seems not to execute if I set below option

this.channel = NettyChannelBuilder.forAddress("localhost", 443)
                                                            .sslContext(GrpcSslContexts.forClient()
                                                                            .trustManager(InsecureTrustManagerFactory.INSTANCE)
                                                                            .build())
                                                             .build();

But when I use OkHttpChannelBuilder in client side, hostname check seems to execute automatically even if I use InsecureTrustManagerFactory.INSTANCE like below

SSLContext context = SSLContext.getInstance("TLS");
context.init(null, InsecureTrustManagerFactory.INSTANCE.getTrustManagers() , null);

this.channel = OkHttpChannelBuilder.forAddress("localhost", 443)
        .sslSocketFactory(context.getSocketFactory())
        .build();

I confirmed that hostname check would not be executed when I overrode hostnameVerifier like below.

this.channel = OkHttpChannelBuilder.forAddress("localhost", 443)
        .sslSocketFactory(context.getSocketFactory())
        .hostnameVerifier((hostname, session) -> true)
        .build();

OkHttpTlsUpgrader.java

if (!hostnameVerifier.verify(canonicalizeHost(host), sslSocket.getSession())) {
  throw new SSLPeerUnverifiedException("Cannot verify hostname: " + host);
}

When using InsecureTrustManagerFactory.INSTANCE to avoid certification verification, hostname check works in okhttp channel, but not works in netty channel. I wonder if there is a need to match the same standards.

There will be two options like below

(1) hostname check is executed regardless of InsecureTrustManagerFactory.INSTANCE when building channel using NettyChannelBuilder

(2) hostname check isn’t executed if InsecureTrustManagerFactory.INSTANCE is used when building channel using OkHttpChannelBuilder

Thank you for reading. If I have misunderstood anything, please let me know.

[kannanjgithub]

In the case of Netty, when using TlsCredentials, both cert chain validation and host name verification happen via X509ExtendedTrustManager at handshake time. Host name verification is instructed by calling X509ExtendedTrustManager.setEndpointIdentificationAlgorithm at handshake time. So when you use an insecure TMF, both cert chain validation and host name verification don't take place.

In the case of OkHttp, we can't use X509ExtendedTrustManager.setEndpointIdentificationAlgorithm which is at Android API level 24 whereas gRPC-Java supports Android API level 21. So the hostname verification behavior happens in gRPC code itself, in io.grpc.okhttp.OkHttpHostnameVerififier. Yes, it doesn't check whether the channel was created with a secure TMF or not, but the ability is override hostname verification is available separately as you pointed out. Given this, there is no compelling reason to make hostname verification in tandem with peer cert chain verification. Also in the future if the minimum Android API level we support becomes 24+ then we will be able to use X509ExtendedTrustManager itself to do both in OkHttp.

[becomeStar]

@kannanjgithub

Thank you for your answer.
I understand why HostNameVerifier is only defined in OkHttpChannelBuilder.
As you mentioned, I guess that there would be no need to override hostnameVerifier that always returns true in test environment when minimum Android API level gRPC-Java support becomes 24+ and X509ExtendedTrustManager.setEndpointIdentificationAlgorithm is used in OkHttp.
When that time comes, server's certificate validation and hostname checking will be disabled just using insecure TMF.

Thanks again for letting me know.

[becomeStar]

I thought about it again and I wonder if my guess is right.
Even if okhttp uses X509ExtendedTrustManager.setEndpointIdentificationAlgorithm in the future, hostName verification will still happen because hostNameVerifier still exists in OkHttpChannelBuilder regardless of insecure TMF. In the future, okhttp will still do hostname verification even if we use X509ExtendedTrustManager.setEndpointIdentificationAlgorithm and insecure TMF. Is my guess reasonable?

[kannanjgithub]

No, if we raise the minimum Android support version and call X509ExtendedTrustManager.setEndpointIdentificationAlgorithm in OkHttp code, then we would avoid calling the HostnameVerifier check for Android 24.0+.

[becomeStar]

@kannanjgithub

Thank you for your kind reply.