Hi Dan,
On 01.02.15 11:52, Daniel Feist wrote:
> 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?
No, it's not supported in JDK6.
Instead of using reflection I made this change [1].
Now on Grizzly requires JDK 1.7 for compilation, but it still supports
JDK 1.6 at runtime.
I doubt many people use 1.6 to compile Grizzly, so IMO it should be safe.
WDYT?
WBR,
Alexey.
[1]
https://java.net/projects/grizzly/sources/git/revision/6a0b99359611d94b7a263a66cdd02a4d0ec0d9ba
> 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
>>>>>>>>>>>>