[jira] [Commented] (HTTPCLIENT-1894) PoolingHttpClientConnectionManager difficulties with client certificate

["Matti Aarnio (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301197#comment-16301197 ] 

Matti Aarnio commented on HTTPCLIENT-1894:
------------------------------------------

At your pointed document there is a mention of:
bq. Examples of such stateful HTTP connections are NTLM authenticated connections and SSL connections with client certificate  authentication.

I disagree on regard of client certificate authentication being stateful at HTTP level.
The SSLSocketFactory takes care of that, and is not co-ordinating certificate changes in between HttpRoute targets.
On every outbound HTTPS socket there either is client certificate exchange (or TLS session resume), or there is not, depending on what server handshakes.
The HttpClient does not know either way, nor does it need to care beyond of the helper tools constructing SSLSocketFactory.

So you are telling that in this example only connections by single thread are pool sharing because each thread has its own context?
[http://hc.apache.org/httpcomponents-client-4.5.x/tutorial/html/connmgmt.html#d5e405]
(Except that each thread executes only once, so it really does not tell which can/should be shared.)

Our public source application using HtttpClient is at github:
[https://github.com/laverca/laverca/blob/master/src/core/fi/laverca/util/LavercaHttpClient.java]

Within each instance of the Laverca, it does:
* Use same client credentials
* Same client certificate on all connections
* A set of URLs connecting to servers, typically different path suffixes, sometimes different servers per service.

We saw the problem of non-sharing connections when calling same service repeatedly (10 threads, 5000 repeats on each thread.)

> PoolingHttpClientConnectionManager difficulties with client certificate
> -----------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1894
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1894
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5.4
>         Environment: Linux x86-64 Oracle JRE
>            Reporter: Matti Aarnio
>
> We run SOAP calls over HTTPS with specific client keypair and certificate attached into communication. We followed tutorial way to create a {{CloseableHttpClient}} with customized {{PoolingHttpClientConnectionManager}}, which has a customized Registry<..> instance with appropriately custom constructed {{SSLSocketFactory}} instance hooked on our specific client keystore.
> However things didn't work as expected. HttpClient kept opening new sockets, and not reusing any.
> We created a wrapper class on top of {{PoolingHttpClientConnectionManager}} which logged the received call parameters, and called original function.
> Then we saw that {{ConnectionRequest requestConnection(HttpRoute route, Object state)}} was called with {{state = null}}, and that {{void releaseConnection(HttpClientConnection managedConn, Object state, long keepalive, TimeUnit tunit)}} was called with {{state != null}}.
> Specifically at release time the state value was HTTPS client certificate Subject in text form, while at request time it was null.
> {color:#205081}*So the pool never found any connections returned into pool because lookup criteria did not match the store keys.*{color}
> Now that we have a wrapper class on top of {{PoolingHttpClientConnectionManager}} we could simply force the state to be null both on request and on release time, and session reuse works.
> We did not use  {{HttpClientContext.setUserToken(Object val)}} before debugging this issue, nor are using any afterwards; during debug we observed that {{requestConnection()}} had our supplied value at {{state}}, and {{releaseConnection}} had null. (Opposite to what it did show without UserToken parameter.)
> So:  Why does releaseConnection() time supply a state value with TLS client keystore certificate subject value when requestConnection() has state=null, and if I supply requestConnection() with non-null state value, then releaseConnection() has null state value?
> There are no pool reuse problems in HTTP URLs, only on HTTPS URLs with client certificate being used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org