I added JIRA issue for this [1] so it exists in issue tracker and will
appear in 2.3.19 release notes.
1.
https://java.net/jira/browse/GRIZZLY-1737
Dan
On Thu, Feb 5, 2015 at 6:53 PM, Daniel Feist <dfeist_at_gmail.com> wrote:
> Just managed to test this and SNI is being sent great:
>
> Using -Djavax.net.debug=ssl I now see:
>
> Extension server_name, server_name: [type=host_name (0), value=localhost]
>
> Dan
>
> On Tue, Feb 3, 2015 at 11:06 PM, Daniel Feist <dfeist_at_gmail.com> wrote:
>> Looks good!
>>
>> I'll let you know if I have any issues, but don't expect any.
>>
>> Dan
>>
>> On Mon, Feb 2, 2015 at 6:23 PM, Oleksiy Stashok
>> <oleksiy.stashok_at_oracle.com> wrote:
>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>