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 13:17:51 GMT
Ok, i think we misunderstood each other. As I wrote in my initial email I
work on highly multithreading environment and I'm expecting all connections
to reuse already initiated SSL session, as they share the same url and
client-side certificate. What you proposed, if I understood you right, is
to keep SSL session per single working thread.
My requirement was met in the old commons-http library as its connection
discriminator was based on host and port exclusively. I'd like to keep this
behavior with using the new API
Regards,
Mateusz



2013/9/5 Oleg Kalnichevski <olegk@apache.org>

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message