Option to supply custom hostname verifier to HTTP client

[Michael McMahon]

There is a fix in progress for 
https://bugs.openjdk.java.net/browse/JDK-8213189
which will allow the "Host" header to be overridden, along with some of 
the other currently
restricted ones.

I don't follow the other point though. With a dummy TrustManager, the 
contents of the
server's certificate is ignored and can contain anything, and be 
self-signed, I believe.

Michael

On 01/11/2018, 19:50, Anders Wisch wrote:
> Yes, although this is more restrictive because it means I have to have common name or subject
> alternative names in the self-signed certificate for “localhost”, “localhost.localdomain”,
> “127.0.0.1”, or similar so that my requests get routed to the local server. Testing hostname-based
> redirects under SSL is also made difficult by the host header being on the restricted list. If
> the hostname verifier used the contents of the host header instead of the URI's host, and the host
> header was customizable, then a self-signed certificate with CN and SAN entries for all of the
> names in question would work (provided I supplied a dummy TrustManager like you suggested).
>
>> On Nov 1, 2018, at 11:45 AM, Michael McMahon<michael.x.mcmahon at oracle.com>  wrote:
>>
>> You could also isolate the behavior to a specific SSLContext (and therefore HttpClient)
>> by initializing the SSLContext with a dummy TrustManager (if it's only for testing).
>>
>> - Michael.
>>
>> On 01/11/2018, 18:09, Anders Wisch wrote:
>>> Thankfully, all of my uses are for testing. To test hostname-based redirects or integration tests of
>>> server code under SSL I start short-lived servers that serve self-signed certificates. Test cases
>>> use HTTP clients that disable hostname verification, connect to a local address and port, and
>>> sometimes vary the contents of the “Host” header. Since tests can run in parallel to speed up suite
>>> execution and since other tests require secure hostname verification, it’s useful to be able to
>>> isolate the behavior.
>>>
>>>> On Nov 1, 2018, at 10:53 AM, Chris Hegarty<chris.hegarty at oracle.com>   wrote:
>>>>
>>>> In order to evaluate this request, can you please provide
>>>> use-cases for such. What “secure” server are you trying
>>>> to connect to that is unwilling to identify itself in its
>>>> certificate.
>>>>
>>>> -Chris.
>>>>
>>>>> On 1 Nov 2018, at 17:48, Anders Wisch<anders at featureshock.com>   wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I think it should be possible to supply a custom javax.net.ssl.HostnameVerifier while building a
>>>>> java.net.http.HttpClient. While it is possible to disable standard hostname verification via the
>>>>> system property “jdk.internal.httpclient.disableHostnameVerification”, this doesn’t allow you to
>>>>> quarantine the behavior to a single HTTP client within the JVM.
>>>>>
>>>>> Thanks for your consideration,
>>>>> Anders Wisch
>>>>>
>>>>>
>