provideTrustManagerByDefault should be false in OpenJDK

[voidzcy]

According to #656 and grpc/grpc-java#6684 (comment), Conscrypt uses Platform's default HostNameVerifier if not explicitly set, which in OpenJDK it is a deny-all implementation. This is problematic as mentioned in #656 (comment) and letting users implement a custom HostNameVerifier is also infeasible (discussed in grpc/grpc-java#6684 (comment)). While there is an option to work around this, which is not to use Conscrypt's TrustManagerImpl. Conscrypt provides API ProviderBuilder#provideTrustManager(boolean provide) to do so. However, its default value of true in OpenJDK is awkward, given that it's default HostNameVerifier is unable to be used. Should it be changed to false?

/cc @ejona86

[ejona86]

It appears this is a regression introduced in f32607b and is preventing Dataproc (see grpc/grpc-java#6684) from upgrading to Conscrypt 2+.

[kruton]

I guess another problem is that setting it to false makes TLS 1.3 break on all Java versions prior to 11 as f32607b indicates.

The reason that the HostnameVerifier is so deferential was that it was impossible to tell what protocol was being used inside the SSLSocket or SSLEngine. With that in mind it seems reasonable to use an internal copy of HostnameVerifier that works with HTTPS when setEndpointIdentificationAlgorithm("HTTPS") is called. That explicitly states that the user wants RFC 2818 semantics for hostname verification.

I do think that HttpsURLConnection having a deny-all implementation is a surprising thing, but that appears to be the state of things on OpenJDK. I don't think it will change for the better any time soon.

[ejona86]

The deny-all implementation of HttpsURLConnection doesn't really matter to most users, because it isn't normally used. It's more of academic interest... except if Conscrypt begins using it on the only platform in which it doesn't work.

My reading of all the code regarding HostnameVerifier is it is more of a legacy API. It seems quite clear setEndpointIdentificationAlgorithm replaced it. Yes, a user can use HostnameVerifier and it will work, but most users won't be using it at all and instead the verification is done in the TrustManger. This isn't surprising, since back in the day all SSL/TLS libraries considered it the responsibility of the "application" (e.g., a http library) to do hostname verification. But then we realized that was horrible because it was trivial to forget and involved to implement and most have newer APIs where the TLS library will do the verification.

[veblush]

As Kenny described, setting provideTrustManagerByDefault to false has the side effect of having an error when trying to use TLSv1.3. We observed this; GoogleCloudPlatform/grpc-gcp-java#56

[yschimke]

Is this closeable with Conscrypt 2.5.0? https://.com/google/conscrypt/pull/876/files

[ejona86]

Yes, this can be closed.