Does JDK6 even support SNI? I had understood it didn't but pherhaps
it is just SNI via new Socket(hostname) that it's not supported in
Java6. Do yo know?
Either way I'd agree would need to use reflection to call
getHostNameString() if JDK needs to be supported.
What I'm less sure about is what the best approach with JDK6 is
(assuming it's supported):
i) SSLContext.createSSLEngine() -> no SNI
ii) getHostString() -> potentially unknown latency of host resolution
being introduced even when user may not care about SNI
iii) Use some other mechanism to determine if the Adress was created
with ip or hostname and only use getHost() in the latter case?
Dan
On Fri, Jan 30, 2015 at 11:10 AM, Oleksiy Stashok
<oleksiy.stashok_at_oracle.com> wrote:
> On 29.01.15 23:35, Daniel Feist wrote:
>>
>> What I don't like about this approach is that
>> java.net.InetSocketAddress#getHostName can provoke a reverse lookup
>> :-(
>
> Agree, in JDK7 there's getHostNameString(), which is probably what we need,
> but we have to be JDK6 compatible.
>
>> We really need to be using the orignal host/ip such that if an ip was
>> specified i) no SNI is used ii) no reverse lookups are performend.
>
> Looks like the only option for now (till we drop JDK6 support) is to use
> reflections and call getHostNameString();
>
> WDYT?
>
> WBR,
> Alexey.
>
>
>
> On Tue, Jan 27, 2015 at 11:15 PM, Oleksiy Stashok
> <oleksiy.stashok_at_oracle.com> wrote:
>>>
>>> Makes sense, just updated SSLFilter on 2.3.x branch.
>>> Can you pls. check if it works for you?
>>>
>>> Thank you.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>> On 27.01.15 06:18, Daniel Feist wrote:
>>>>
>>>> In grizzly or AHC?
>>>>
>>>> In my mind there is no reason why the Grizzly SSLFilter shoudn't use
>>>> SSLContext.createSSLEngine(host, port). This would mean i) no changes
>>>> to AHC ii) Grizzly will support client SNI by default which I don't
>>>> see an issue with.
>>>>
>>>> BTW, I agree using SSLContext.createSSLEngine(host, port) is most
>>>> correct/direct approach. What i did creating socket with hostname is
>>>> kinda indirect, I used it primrily as a way of getting httpClient 3.1
>>>> to do SNI without needs to modify it.
>>>>
>>>> Dan
>>>>
>>>> On Mon, Jan 26, 2015 at 11:48 AM, Oleksiy Stashok
>>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>
>>>>> I'll take a look at AHC and make it use
>>>>> SSLContext.createSSLEngine(host,
>>>>> port).
>>>>> Can I ask you to file a bug for it?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>>
>>>>> On 23.01.15 13:05, Daniel Feist wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> AHC uses the SSLFilter and doesn't use
>>>>>> SSLContext.createSSLEngine(host, port) anywhere and so obviously
>>>>>> doesn't work. If SSLFilter is switched out for SNIFilter than things
>>>>>> work. But i beleive there are three potential options and I'm not
>>>>>> sure which is best
>>>>>>
>>>>>> 1) Switch out us the implementation SwitchingSSLFilter extends from
>>>>>> SSLFilter to SNIFilter.
>>>>>> 2) Use SSLContext.createSSLEngine(host, port) in AHC
>>>>>> 3) Simply create socket with String host name and not InetAddress.
>>>>>>
>>>>>> I just added support for use of HttpClient31 via doing 3) and it
>>>>>> works, java7+ handles the rest.
>>>>>>
>>>>>> Fix:
>>>>>>
>>>>>>
>>>>>> https://github.com/mulesoft/mule/commit/416f594ae8d99eb1f8304f0bb549f372825e241c
>>>>>>
>>>>>> Context regarding this approach for enabling SNI:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/HTTPCLIENT-1119?focusedCommentId=13769887&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13769887
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> On Fri, Jan 23, 2015 at 8:49 PM, Oleksiy Stashok
>>>>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>>>
>>>>>>> Exactly, it's enough to create SSLEngine using
>>>>>>> SSLContext.createSSLEngine(host, port) and pass the host name.
>>>>>>> I don't remember what we do in ahc, so will appreciate if you can
>>>>>>> doublecheck that.
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>> WBR,
>>>>>>> Alexey.
>>>>>>>
>>>>>>>
>>>>>>> On 23.01.15 12:21, Daniel Feist wrote:
>>>>>>>>
>>>>>>>> Simply replace SSLFilter with SNIFilter in the provider
>>>>>>>> implementation.
>>>>>>>>
>>>>>>>> But TBH looking at SNI more closely I dont think this approach with
>>>>>>>> SNIFilter is even required for outbound http. Ensuring the socket
>>>>>>>> is
>>>>>>>> created with the hostname and not ip is enough. So hold off for a
>>>>>>>> while and I'll come back to you..
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>> On Fri, Jan 23, 2015 at 7:42 PM, Oleksiy Stashok
>>>>>>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Pls. share the "hack" - I can commit it to ahc.
>>>>>>>>>
>>>>>>>>> WBR,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 23.01.15 04:35, Daniel Feist wrote:
>>>>>>>>>>
>>>>>>>>>> Fanstastic, works a treat. Just had to hack AHC a bit to use it
>>>>>>>>>> :-(
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 23, 2015 at 1:14 AM, Oleksiy Stashok
>>>>>>>>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>
>>>>>>>>>>> yes, SNIFilter is compatible with SSLFilter, it just extends it
>>>>>>>>>>> with
>>>>>>>>>>> SNI
>>>>>>>>>>> support.
>>>>>>>>>>>
>>>>>>>>>>> WBR,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 22.01.15 16:44, Daniel Feist wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Just a very quick question. Is the use of SNIFilter instead of
>>>>>>>>>>>> SSLFilter fully compatible with the SSLFilter.
>>>>>>>>>>>>
>>>>>>>>>>>> i.e Can i always use the SNIFilter for SSL and have SNI
>>>>>>>>>>>> supported,
>>>>>>>>>>>> but
>>>>>>>>>>>> also not have to worry if SNI isn't supported/required by the
>>>>>>>>>>>> target
>>>>>>>>>>>> server? It looks like it is, but this isn't clear from javadoc,
>>>>>>>>>>>> so
>>>>>>>>>>>> wanted to check.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks!
>>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>>
>