[
https://issues.apache.org/jira/browse/HTTPCORE-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17337793#comment-17337793
]
ASF subversion and git services commented on HTTPCORE-676:
----------------------------------------------------------
Commit 5e15a6fe12c53273b1de629e49c3a1cda0e2a3dc in httpcomponents-core's branch
refs/heads/master from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=5e15a6f ]
HTTPCORE-676: fixed incorrect handling of TLS renegotiation by non-blocking i/o
sessions
> TLS renegotiation seems to not be handled properly
> --------------------------------------------------
>
> Key: HTTPCORE-676
> URL: https://issues.apache.org/jira/browse/HTTPCORE-676
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 5.1
> Reporter: synth3
> Priority: Major
> Attachments: apache_hc5_tls_log_excerpt.log,
> java_httpclient_tls_log_excerpt.log
>
>
> Hi there,
> I noticed that TLS renegotiation seems to not be handled by HTTP-Core (I
> stumbled across this while using the Async HTTP-Client with HTTP1.1).
> Trying to perform an HTTP-Request to a server that requires to renegotiate
> the TLS connection by sending a [TLS Hello
> Request|http://tools.ietf.org/html/rfc5246#section-7.4.1.1] causes the
> request to hang (I guess until a server or a client timeout kicks in) and
> then fail with a generic error (e.g. "execution failed: Connection is
> closed").
> I was able to reproduce the issue using {{httpd}} and a {{Location}} entry
> inside a virtual host that requests a client certificate (as in mTLS).
> The following minimal Apache-Configuration can be used to reproduce the
> problem (note that - for the sake of painless testing - the client cert is
> optional so the client does not have to present a certificate for performing
> the request successfully):
> {code:java}
> Listen 8445
> SSLProtocol -all +TLSv1.2
> <VirtualHost *:8445>
> ServerName some.host.de
> SSLEngine on
>
> SSLCertificateFile "path_to_some_cert.crt"
> SSLCertificateKeyFile "path_to_some_key.key"
>
> ProxyPass / http://some.target/
>
> <Location /the_resource_with_optional_client_cert>
> SSLVerifyClient optional_no_ca
> </Location>
> </VirtualHost>
> {code}
> - With HTTP-Client 5 a call to
> {{[https://localhost:8445/the_resource_with_optional_client_cert]}} will not
> succeed
> - The {{java.net.http.HttpClient}}, popular Browsers and Postman had no
> problem with performing the request
> ** (at first I was not sure if that's an rather exotic thing that no one
> understands anyway)
> h2. Some logs
> I Attached two excerpts of logs with {{javax.net.debug=all}} and DEBUG-output
> for HC5:
> - {{apache_hc5_tls_log_excerpt.log}} the log-output produced by HC5
> - {{java_httpclient_tls_log_excerpt.log}} the log-output produced by
> {{java.net.http.HttpClient}}
> The interesting part in {{apache_hc5_tls_log_excerpt.log}} starts at
> {{10:59:39.454}} where HC then waits 20 seconds until it consumes the
> {{HelloRequest}}.
> The comparable part in {{java_httpclient_tls_log_excerpt.log}} starts at
> {{11:37:30.017}}.
> h2. Tests
> I looked into adjusting the configuration at
> [https://github.com/apache/httpcomponents-core/tree/master/httpcore5-testing/docker/apache-httpd],
> but I had some trouble understanding where the exposed ports for the image
> are configured in the configuration (and where to configure/expose the new
> https port). In the HTTP-Client project it is more clear as there are the
> {{EXPOSE}}-entries in the dockerfile.
> Another thing I asked myself is: Where to best place a test?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
