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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>