[jira] [Resolved] (HTTPCORE-676) TLS renegotiation seems to not be handled properly

["Oleg Kalnichevski (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HTTPCORE-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCORE-676.
----------------------------------------
    Fix Version/s: 5.2-alpha1
                   5.1.1
                   5.0.4
       Resolution: Fixed

[~synth3] Please re-test with a snapshot from one of the active 5.x branches (5.0.x, 5.1.x or master).

Oleg

> 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
>             Fix For: 5.0.4, 5.1.1, 5.2-alpha1
>
>         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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org