[Hsnmohd]

AbstractClientTlsStrategy lost its null-verifier fallback in #649, so new ConscryptClientTlsStrategy(sslContext) (which hardcodes CLIENT) and setHostVerificationPolicy(CLIENT) without a verifier skip both endpoint identification and the post-handshake check, and a real exchange with https://some-other-host against a CN=localhost certificate returns 200 through classic, async and a Conscrypt engine, so restore HttpsSupport.getDefaultHostnameVerifier() for CLIENT and BOTH.

[arturobernalg]

The default hostname verifier fallback was intentionally removed in #649.

Would it be better to fix the Conscrypt constructor to use BUILTIN by default, and reject CLIENT without a verifier, rather than restoring the fallback in AbstractClientTlsStrategy?

I'd prefer to preserve the existing separation between verification policy and verifier configuration.

[ok2c]

@Hsnmohd I agree with @arturobernalg Let's fix it in Conscrypt classes instead.

[ok2c]

@Hsnmohd This is wrong and must be fixed.

    public ConscryptClientTlsStrategy(
            final SSLContext sslContext,
            final String[] supportedProtocols,
            final String[] supportedCipherSuites,
            final SSLBufferMode sslBufferManagement,
            final HostnameVerifier hostnameVerifier) {
        this(sslContext, supportedProtocols, supportedCipherSuites, sslBufferManagement, HostnameVerificationPolicy.CLIENT, hostnameVerifier); /
    }