Oleg Kalnichevski commented on HTTPCLIENT-1784:


HC fluent uses the default SSL socket factory as provided by the JRE, 
HttpClient does not (by default). This is likely the reason for different 
behavior with IBM Java.

What is not entirely clear to me is the expected usage of the IBMJSSE2 provider

Oracle -> enables all versions of TLS supported by the provider

IBM -> enables TLS version 1 only

How would one initialize all supported TLS versions and let the endpoints 
select the highest common version during the SSL handshake?



> TLS Client Hello is always TLS 1.0 (0x0301) under IBM Java
> ----------------------------------------------------------
>                 Key: HTTPCLIENT-1784
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1784
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5.2
>         Environment: IBM Java, many versions including latest Java 8.
>            Reporter: Bruce Adams
>              Labels: tls
>         Attachments: ApacheGet.java, FluentGet.java, Get.java
> A simple client program fails to connect to any site that _requires_ TLSv1.2. 
> The attached {{ApacheGet.java}} program, run with 
> org.apache.httpcomponents/httpclient version 4.5.2 and given the URL 
> https://www.sandbox.paypal.com fails with:
> bq. javax.net.ssl.SSLHandshakeException: Received fatal alert: 
> handshake_failure
> when run on the latest released IBM Java, {{pxa6480sr3fp12-20160919_01(SR3 
> FP12)}} (available in a Docker image {{ibmcom/ibmjava:8-sdk}}). The same run 
> is successful on a recent Oracle Java 8.
> The similar, simple, {{Get.java}} program that uses the built-in Java 
> libraries instead of Apache HttpClient works fine on both IBM Java and Oracle 
> Java.

This message was sent by Atlassian JIRA

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

Reply via email to