SNIFilter for Client

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

SNIFilter for Client

Daniel Feist
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
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

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

Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
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
<[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

oleksiys
Administrator
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
> <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
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
<[hidden email]> 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
>> <[hidden email]> 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
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

oleksiys
Administrator
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
> <[hidden email]> 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
>>> <[hidden email]> 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
>>>>

Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
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
<[hidden email]> 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
>> <[hidden email]> 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
>>>> <[hidden email]> 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
>>>>>
>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

oleksiys
Administrator
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
> <[hidden email]> 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
>>> <[hidden email]> 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
>>>>> <[hidden email]> 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
>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
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
<[hidden email]> 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
>> <[hidden email]> 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
>>>> <[hidden email]> 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
>>>>>> <[hidden email]> 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
>>>>>>>
>>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

oleksiys
Administrator
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
> <[hidden email]> 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
>>> <[hidden email]> 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
>>>>> <[hidden email]> 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
>>>>>>> <[hidden email]> 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
>>>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
What I don't like about this approach is that
java.net.InetSocketAddress#getHostName can provoke a reverse lookup
:-(

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.

Dan

On Tue, Jan 27, 2015 at 11:15 PM, Oleksiy Stashok
<[hidden email]> 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
>> <[hidden email]> 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
>>>> <[hidden email]> 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
>>>>>> <[hidden email]> 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
>>>>>>>> <[hidden email]> 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
>>>>>>>>>
>>>>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

oleksiys
Administrator
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
<[hidden email]> 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
>>> <[hidden email]> 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
>>>>> <[hidden email]> 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
>>>>>>> <[hidden email]> 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
>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
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
<[hidden email]> 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
> <[hidden email]> 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
>>>> <[hidden email]> 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
>>>>>> <[hidden email]> 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
>>>>>>>> <[hidden email]> 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
>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>
>>>>>>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

oleksiys
Administrator
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
> <[hidden email]> 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
>> <[hidden email]> 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
>>>>> <[hidden email]> 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
>>>>>>> <[hidden email]> 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
>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
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
<[hidden email]> 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
>> <[hidden email]> 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
>>> <[hidden email]> 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
>>>>>> <[hidden email]> 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
>>>>>>>> <[hidden email]> 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
>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
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 <[hidden email]> 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
> <[hidden email]> 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
>>> <[hidden email]> 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
>>>> <[hidden email]> 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
>>>>>>> <[hidden email]> 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
>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: SNIFilter for Client

Daniel Feist
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 <[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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
>>>> <[hidden email]> 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
>>>>> <[hidden email]> 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
>>>>>>>> <[hidden email]> 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
>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>