Inconsistent HostnameVerifier behavior between backends

[kevinoid]

The contract/behavior of HostnameVerifier differs between the JDK and Netty backends. For the JDK backend, the HostnameVerifier is only called in the case that the connection hostname does not match the certificate hostname (which is why HttpsURLConnection.getDefaultHostnameVerifier returns false in all cases). In contrast, the Netty backend always calls the HostnameVerifier, which places the burden of wildcard and subject alt name matching on the client code.

It would make SSL certificate verification much easier for client code if the behavior was consistent and, if the behavior is to call HostnameVerifier in all cases, to provide an implementation which client code could extend that takes care of this common case.

For reference, the implementation I am using (which emulates the JDK, but requires using Sun internal proprietary APIs) is here.

[harbulot]

For reference, how a hostname verifier should behave is standardised in RFC 2818, Section 3.1 (and in RFC 6125).

The default hostname verifier used by HttpsURLConnection in Java follows this specification strictly. Some other clients do not. In particular, some clients are more tolerant regarding IP addresses places in the Common Name (CN) of the Subject DN (whereas IP addresses should only be in a Subject Alternative Name of IPaddress type). This is discussed here: http://stackoverflow.com/questions/8443081/how-are-ssl-certificate-server-names-resolved-can-i-add-alternative-names-using

[wsargent]

This can be closed out because #392 drops the JDK provider completely.

[slandelle]

Right, thanks!