hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mateusz P <log...@gmail.com>
Subject Re: HTTPClient 4.3-beta2: Failure to re-use connections with Mutual SSL Auth
Date Thu, 05 Sep 2013 10:55:10 GMT
Oleg,
What in case sacrificing performance is not possible?
The system I work on is a ESB gateway with high volume traffic and
processing requests one by one is not an option at all.
However, all requests go to the same service and use exactly the same
client-side certificate in mutual SSL handshake, so they could reuse the
connections.
The problem would be easier to solve if there would be separation between
client context (holding all information specific for all connections like
security context, cookie store etc) and execution context (holding
information specific for a particular connection).
My temporary solution is to save the first request's context and I create
my own BasicContext for every subsequent request and provide USER_TOKEN to
it from the initially saved http context.
If separation is not an option, I would appreciate utils class to
extract/store client/execution context's attributes in one call. Having
that I could improve my solution
Please let me know what are your thoughts on that
Regards,
Mateusz


On Mon, 2013-08-12 at 12:54 -0700, Erik Pilz wrote:

> > Hi Oleg,
> >
> > Thanks for the clear and thoughtful reply explaining the design. For my
> own
> > edification I was hoping you could elaborate on the scenario where
> another
> > consumer with a different security context would introduce a risk or
> > problem. Are you referring to clients using a SSLContext other than the
> > system default?
> >
> > Thanks,
> > Erik
> >
>
> Hi Erik
>
> Consider the following scenario. Multiple threads consume the same
> service (the same route) but using a different SSLContext with the
> client auth set to required. The service handles requests differently
> based on the security principal of the client certificate (user role).
> You would not want HttpClient to carelessly hand out a persistent
> connection to that service to the very first consumer that happens to
> request it, would you?
>
> It is a fairly uncommon scenario, but when it comes to security, one
> better be safe than sorry. Security considerations override those of
> performance.
>
> Hope this helps
>
> Oleg
>
> >
> > On Sun, Aug 11, 2013 at 3:34 AM, Oleg Kalnichevski <olegk@apache.org>
> wrote:
> >
> > > On Fri, 2013-08-09 at 15:16 -0700, Erik Pilz wrote:
> > > > We're migrating an old application from Java's HttpsUrlConnection to
> > > > HttpClient. After running a performance test we found a high cost
> around
> > > > connection acquisition. A bit of debugging later led me to find that
> > > we're
> > > > not getting the full benefit of pooled connections. What I eventually
> > > found
> > > > is that I have to create a HttpClientContext and populate the
> userToken
> > > > with some object and use HttpClient#execute(method, context). This
> wasn't
> > > > obvious to me; is this intentional or did I just find a workaround
> to a
> > > bug?
> > >
> > > ...
> > >
> > > > Calling HttpClient#execute(method) will create a context whose
> userToken
> > > is
> > > > null. To work around the behavior it's instead necessary to create an
> > > > HttpClientContext and populate it with a userToken of your own (it
> can be
> > > > any object); this will then be used as the state in the available
> > > > connections instead of the principal from the SSLSession; you then
> use
> > > > HttpClient#execute(method, context) in place of
> > > HttpClient#execute(method).
> > > >
> > > > Thanks,
> > > > Erik
> > >
> > > Hi Erik
> > >
> > > This is by design and not a defect.
> > >
> > > Mutually authenticated SSL connections are considered state-full and
> > > special measures are taken to make sure they cannot be leased to a
> > > consumer with a different security context. Their state is represented
> > > by a user token, which is by default the security principal of the
> > > client certificate.
> > >
> > > There are two ways you could resolve the issue
> > >
> > > (1) Disable connection state management if your application does not
> > > need to maintain a different security context per worker thread
> > >
> > > ---
> > > CloseableHttpClient client = HttpClients.custom()
> > >     .disableConnectionState()
> > >     .build();
> > > ---
> > >
> > > (2) Simply make related requests share the same context (recommended).
> > > In this case SSL security principal of the initial request will be
> added
> > > to the execution context as a user token and propagated to all
> > > subsequent requests. When leasing a persistent connection from the
> > > connection pool HttpClient will use the user token to request a
> > > connection with a specific state / security context.
> > >
> > > ---
> > > CloseableHttpClient client = HttpClients.custom()
> > >         .build();
> > > HttpClientContext context = HttpClientContext.create();
> > > HttpGet get1 = new HttpGet("https://myhost/this");
> > > CloseableHttpResponse response1 = client.execute(get1, context);
> > > try {
> > >
> > > } finally {
> > >     response1.close();
> > > }
> > > HttpGet get2 = new HttpGet("https://myhost/that");
> > > CloseableHttpResponse response2 = client.execute(get2, context);
> > > try {
> > >
> > > } finally {
> > >     response1.close();
> > > }
> > > ---
> > >
> > > Oleg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message