Server closes connections made using httpclient and Java 7

Question

I am trying to connect to a remote server that serves certificates using SNI. I noticed that the server is closing connections made when I compile and run code using Java 7 and not when I compile and run it via Java 8.

Below is the code that i made to test this assumption. I switch Java versions and run the code and get different results.

public static void getRequest() throws IOException, NoSuchAlgorithmException, KeyManagementException {
    String url = "https://sorry i can not share the exact url because of privacy concerns";

    HttpClient client = getClientInstance();
    HttpGet request = new HttpGet(url);

    HttpResponse response = client.execute(request);

    System.out.println("Response Code : "
            + response.getStatusLine().getStatusCode());

    BufferedReader rd = new BufferedReader(new InputStreamReader(response.getEntity().getContent()));

    StringBuffer result = new StringBuffer();
    String line = "";
    while ((line = rd.readLine()) != null) {
        result.append(line);
    }
    System.out.println("####### the result is");
    System.out.println(result.toString());
}

private static org.apache.http.client.HttpClient getClientInstance() throws KeyManagementException, NoSuchAlgorithmException {
    RequestConfig defaultRequestConfig = RequestConfig.copy(RequestConfig.DEFAULT)
            .setConnectTimeout(60 * 1000)
            .setSocketTimeout(60 * 1000)
            .setConnectionRequestTimeout(60 * 1000)
            .build();

    return HttpClientBuilder.create().setDefaultRequestConfig(defaultRequestConfig).build();
}

Has someone ever experienced such an issue and fixed it? I know the ultimate fix would be to use Java 8 but that's not a task that I can do within my current time constraints since the entire codebase i was debugging is huge and has dependencies that might not work well with Java 7.

The exception being thrown is as below;

*** ClientHello, TLSv1
RandomCookie:  GMT: 1472095425 bytes = { 254, 51, 194, 246, 77, 6, 185, 8, 224, 187, 85, 225, 133, 128, 122, 1, 245, 13, 230, 239, 156, 93, 164, 184, 251, 159, 111, 60 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: lasclev.org]
***
main, WRITE: TLSv1 Handshake, length = 169
main, handling exception: java.net.SocketException: Connection reset
main, SEND TLSv1 ALERT:  fatal, description = unexpected_message
main, WRITE: TLSv1 Alert, length = 2
main, Exception sending alert: java.net.SocketException: Broken pipe
main, called closeSocket()
java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:196)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
    at sun.security.ssl.InputRecord.read(InputRecord.java:480)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)

Also below is a screenshot of the SSL Labs test that i carried out earlier.

score 2 · Answer 1 · answered Mar 07 '17 at 12:30

You didn't show the part of the SSLLabs report where it lists protocols supported, but I bet you'll find this server supports only TLSv1.2 or maybe TLSv1.2 and TLSv1.1, but not TLSv1.0. In particular, systems handling payment transactions subject to PCI DSS are generally prohibited from using TLSv1.0 (aka 'Early TLS') apparently due to an overreaction to BEAST (which remains 4.3 in NVD although it doesn't deserve to). Although in this case the server should give alert 70 or maybe 71 or 40 not just reset (or close). Java7 (JSSE) client by default does not do TLSv1.2 or TLSv1.1.

It may depend on the version of HttpClient -- I have 4.5 -- but I think you can either:

create an appropriately configured SSLConnectionSocketFactory and .setSSLSocketFactory to it, or
.useSystemProperties(true) and set sysprop https.protocols as appropriate either TLSv1.2 or TLSv1.1,TLSv1.2 (also used by javax.net.HttpsURLConnection), but this may affect other things you don't want (see the javadoc for useSystemProperties)

What you are suggesting totally makes sense, however it didn't work for me. The remote server is something i didn't have control over. Due to time constraints I made a nasty workaround for this by using curl via `Runtime.getRuntime().exec` — ivanorone, Mar 29 '17 at 08:03

Server closes connections made using httpclient and Java 7

1 Answers1

Linked