You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Ivan Brencsics <iv...@gmail.com> on 2016/06/07 09:06:55 UTC
SSL problem when using pooling connection manager
Hi,
I have some trouble using SSL together
with PoolingHttpClientConnectionManager.
I create an HttpClient by setting both the SSLContext and ConnectionManager
and the SSLContext is ignored. I read that others had the same problem and
solved it by adding a Socket Factory Registry to the Connection Manager.
However, I dont find this a good solution. I would like to create one and
only one connection pool for my application, and then provide it to all
HttpClient instances I create later on. When I instantiate the connection
pool, I dont know exactly what connections I will create later with what
SSL parameters. Your solution assumes that when instantiating the
PoolingHttpClientConnectionManager, we are already aware of all the SSL
settings that we will ever use. This is very often not the case.
Why are the SSL settings so tightly coupled to
PoolingHttpClientConnectionManager? And do I understand correctly that if I
am using SSL, I should create separate PoolingHttpClientConnectionManager
instances towards the different remote servers?
Thanks,
Ivan
Re: SSL problem when using pooling connection manager
Posted by Ivan Brencsics <iv...@gmail.com>.
@Oleg: Ok thanks, I see your point.
@Brent: Thanks a lot, your examples really helped me a lot. For some reason
I did not think about implementing my own LayeredConnectionSocketFactory,
but now it is clear to me what to do.
2016-06-07 18:04 GMT+02:00 Brent Putman <pu...@georgetown.edu>:
>
>
> On 6/7/16 11:02 AM, Oleg Kalnichevski wrote:
> > On Tue, 2016-06-07 at 15:45 +0200, Ivan Brencsics wrote:
> >> Hi Oleg,
> >>
> >> Thanks for your answer, maybe I did not explain clearly our use case. We
> >> need to call several external systems over HTTP, and every system has
> >> different requirements. All need TLS, but some need client certificate,
> >> others not, some of them needs a certain client certificate that differs
> >> from others, some of them wants to exclude certain protocols and cipher
> >> suites. My idea is that we need as many SSLConnectionFactiories as many
> >> external systems. This is what I cant achieve now with a single
> HttpClient
> >> / PoolingHttpClientConnectionManager. The
> PoolingHttpClientConnectionManager
> >> can be given a single HTTPS connection factory, but I would need
> multiple
> >> different factories I suspect. Am I wrong with this?
> >>
> > No need for multiple factories. A single factory should be perfectly
> > capable of setting different SSL contexts based on hostname / DNS /
> > HttpContext attributes.
> >
> > Oleg
> >
>
> FWIW, as an example, this is actually exactly what we do in
> OpenSAML/Shibboleth. We have a couple of custom TLS socket factory
> impls which allow specifying some things on a per-request basis using
> HttpContext attributes: TLS protocols; TLS cipher suites; hostname
> verifier; client certificate; and trust engine (our abstraction for how
> the TLS server certificate is evaluated.
>
>
> http://git.shibboleth.net/view/?p=java-support.git;a=blob;f=src/main/java/net/shibboleth/utilities/java/support/httpclient/TLSSocketFactory.java;hb=HEAD
>
>
> http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-security-impl/src/main/java/org/opensaml/security/httpclient/impl/SecurityEnhancedTLSSocketFactory.java?view=markup
>
>
> For project API reasons, the client cert and trust engine support is in
> the second class, which just wraps a "real" TLS socket factory, such as
> an instance of the first.
>
> Thanks,
> Brent
>
>
>
Re: SSL problem when using pooling connection manager
Posted by Brent Putman <pu...@georgetown.edu>.
On 6/7/16 11:02 AM, Oleg Kalnichevski wrote:
> On Tue, 2016-06-07 at 15:45 +0200, Ivan Brencsics wrote:
>> Hi Oleg,
>>
>> Thanks for your answer, maybe I did not explain clearly our use case. We
>> need to call several external systems over HTTP, and every system has
>> different requirements. All need TLS, but some need client certificate,
>> others not, some of them needs a certain client certificate that differs
>> from others, some of them wants to exclude certain protocols and cipher
>> suites. My idea is that we need as many SSLConnectionFactiories as many
>> external systems. This is what I cant achieve now with a single HttpClient
>> / PoolingHttpClientConnectionManager. The PoolingHttpClientConnectionManager
>> can be given a single HTTPS connection factory, but I would need multiple
>> different factories I suspect. Am I wrong with this?
>>
> No need for multiple factories. A single factory should be perfectly
> capable of setting different SSL contexts based on hostname / DNS /
> HttpContext attributes.
>
> Oleg
>
FWIW, as an example, this is actually exactly what we do in
OpenSAML/Shibboleth. We have a couple of custom TLS socket factory
impls which allow specifying some things on a per-request basis using
HttpContext attributes: TLS protocols; TLS cipher suites; hostname
verifier; client certificate; and trust engine (our abstraction for how
the TLS server certificate is evaluated.
http://git.shibboleth.net/view/?p=java-support.git;a=blob;f=src/main/java/net/shibboleth/utilities/java/support/httpclient/TLSSocketFactory.java;hb=HEAD
http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-security-impl/src/main/java/org/opensaml/security/httpclient/impl/SecurityEnhancedTLSSocketFactory.java?view=markup
For project API reasons, the client cert and trust engine support is in
the second class, which just wraps a "real" TLS socket factory, such as
an instance of the first.
Thanks,
Brent
Re: SSL problem when using pooling connection manager
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2016-06-07 at 15:45 +0200, Ivan Brencsics wrote:
> Hi Oleg,
>
> Thanks for your answer, maybe I did not explain clearly our use case. We
> need to call several external systems over HTTP, and every system has
> different requirements. All need TLS, but some need client certificate,
> others not, some of them needs a certain client certificate that differs
> from others, some of them wants to exclude certain protocols and cipher
> suites. My idea is that we need as many SSLConnectionFactiories as many
> external systems. This is what I cant achieve now with a single HttpClient
> / PoolingHttpClientConnectionManager. The PoolingHttpClientConnectionManager
> can be given a single HTTPS connection factory, but I would need multiple
> different factories I suspect. Am I wrong with this?
>
No need for multiple factories. A single factory should be perfectly
capable of setting different SSL contexts based on hostname / DNS /
HttpContext attributes.
Oleg
> Ivan
>
> 2016-06-07 15:18 GMT+02:00 Oleg Kalnichevski <ol...@apache.org>:
>
> > On Tue, 2016-06-07 at 11:06 +0200, Ivan Brencsics wrote:
> > > Hi,
> > >
> > > I have some trouble using SSL together
> > > with PoolingHttpClientConnectionManager.
> > >
> > > I create an HttpClient by setting both the SSLContext and
> > ConnectionManager
> > > and the SSLContext is ignored. I read that others had the same problem
> > and
> > > solved it by adding a Socket Factory Registry to the Connection Manager.
> > > However, I dont find this a good solution. I would like to create one and
> > > only one connection pool for my application, and then provide it to all
> > > HttpClient instances I create later on.
> >
> > What is the point doing so? You might as well have just one instance of
> > HttpClient which is basically recommended anyway.
> >
> > > When I instantiate the connection
> > > pool, I dont know exactly what connections I will create later with what
> > > SSL parameters. Your solution assumes that when instantiating the
> > > PoolingHttpClientConnectionManager, we are already aware of all the SSL
> > > settings that we will ever use. This is very often not the case.
> > >
> > > Why are the SSL settings so tightly coupled to
> > > PoolingHttpClientConnectionManager?
> >
> > Because the pool manager is responsible for keeping track of persistent
> > connection state.
> >
> > > And do I understand correctly that if I
> > > am using SSL, I should create separate PoolingHttpClientConnectionManager
> > > instances towards the different remote servers?
> > >
> >
> > No, you should not.
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL problem when using pooling connection manager
Posted by Ivan Brencsics <iv...@gmail.com>.
Hi Oleg,
Thanks for your answer, maybe I did not explain clearly our use case. We
need to call several external systems over HTTP, and every system has
different requirements. All need TLS, but some need client certificate,
others not, some of them needs a certain client certificate that differs
from others, some of them wants to exclude certain protocols and cipher
suites. My idea is that we need as many SSLConnectionFactiories as many
external systems. This is what I cant achieve now with a single HttpClient
/ PoolingHttpClientConnectionManager. The PoolingHttpClientConnectionManager
can be given a single HTTPS connection factory, but I would need multiple
different factories I suspect. Am I wrong with this?
Ivan
2016-06-07 15:18 GMT+02:00 Oleg Kalnichevski <ol...@apache.org>:
> On Tue, 2016-06-07 at 11:06 +0200, Ivan Brencsics wrote:
> > Hi,
> >
> > I have some trouble using SSL together
> > with PoolingHttpClientConnectionManager.
> >
> > I create an HttpClient by setting both the SSLContext and
> ConnectionManager
> > and the SSLContext is ignored. I read that others had the same problem
> and
> > solved it by adding a Socket Factory Registry to the Connection Manager.
> > However, I dont find this a good solution. I would like to create one and
> > only one connection pool for my application, and then provide it to all
> > HttpClient instances I create later on.
>
> What is the point doing so? You might as well have just one instance of
> HttpClient which is basically recommended anyway.
>
> > When I instantiate the connection
> > pool, I dont know exactly what connections I will create later with what
> > SSL parameters. Your solution assumes that when instantiating the
> > PoolingHttpClientConnectionManager, we are already aware of all the SSL
> > settings that we will ever use. This is very often not the case.
> >
> > Why are the SSL settings so tightly coupled to
> > PoolingHttpClientConnectionManager?
>
> Because the pool manager is responsible for keeping track of persistent
> connection state.
>
> > And do I understand correctly that if I
> > am using SSL, I should create separate PoolingHttpClientConnectionManager
> > instances towards the different remote servers?
> >
>
> No, you should not.
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: SSL problem when using pooling connection manager
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2016-06-07 at 11:06 +0200, Ivan Brencsics wrote:
> Hi,
>
> I have some trouble using SSL together
> with PoolingHttpClientConnectionManager.
>
> I create an HttpClient by setting both the SSLContext and ConnectionManager
> and the SSLContext is ignored. I read that others had the same problem and
> solved it by adding a Socket Factory Registry to the Connection Manager.
> However, I dont find this a good solution. I would like to create one and
> only one connection pool for my application, and then provide it to all
> HttpClient instances I create later on.
What is the point doing so? You might as well have just one instance of
HttpClient which is basically recommended anyway.
> When I instantiate the connection
> pool, I dont know exactly what connections I will create later with what
> SSL parameters. Your solution assumes that when instantiating the
> PoolingHttpClientConnectionManager, we are already aware of all the SSL
> settings that we will ever use. This is very often not the case.
>
> Why are the SSL settings so tightly coupled to
> PoolingHttpClientConnectionManager?
Because the pool manager is responsible for keeping track of persistent
connection state.
> And do I understand correctly that if I
> am using SSL, I should create separate PoolingHttpClientConnectionManager
> instances towards the different remote servers?
>
No, you should not.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org