hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HTTPClient 4.3-beta2: Failure to re-use connections with Mutual SSL Auth
Date Thu, 05 Sep 2013 12:49:54 GMT
On Thu, 2013-09-05 at 14:43 +0200, Mateusz P wrote:
> Oleg,
> While reusing http context I encountered on thread-safety issue though.
> A *HttpRequest *is processed by *DefaultRequestDirector *which, among
> others, sets up currently used connection on the context object (a line
> from v4.2.5):
> 
> *515: context.setAttribute(ExecutionContext.HTTP_CONNECTION, managedConn);*
> 
> This value is extracted later on by *DefaultUserTokenHandler* and used to
> retrieve user principal from SSL session associated with the connection.
> The multithreaded case lead to situation when the session is replaced
> between storing and retrieving,  which, causes
> *DefaultUserTokenHandler*cannot find the user principal.
> 
> Regards,
> Mateusz
> 

I am sorry but I fail to see a threading issue here or i do not quite
understand what 'when the session is replaced between storing and
retrieving' actually means. Neither HttpContext nor HttpConnection
objects are thread safe and therefore may not be shared concurrently by
multiple threads.

Oleg

> 
> 
> 2013/9/5 Oleg Kalnichevski <olegk@apache.org>
> 
> > On Thu, 2013-09-05 at 12:55 +0200, Mateusz P wrote:
> > > 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
> > >
> >
> > Mateusz
> >
> > There is absolutely nothing that prevents you from using the same
> > HttpContext per worker thread. Those contexts could share the same
> > cookie store, credentials provider or any other thread safe object.
> >
> > If the same connection pool is not used anywhere else you might as well
> > disable connection state tracking.
> >
> > Oleg
> >
> > >
> > > 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
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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


Mime
View raw message