Websphere 8.5: SSL ClientHello with TLSv1 and only one cipher (SSL_RSA_WITH_3DES_EDE_CBC_SHA)

It seems that okhttp does not load a correct a SSL context configuration during the ClientHello phase during a SSL handshake, when deployed on Websphere 8.5 (tested on 8.5.5.0 and 8.5.5.10).

Here the code we use in our test servlet:

OkHttpClient client = new OkHttpClient();
X509TrustManager trustManager;
SSLSocketFactory sslSocketFactory;
try {

	TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(
			TrustManagerFactory.getDefaultAlgorithm());
	trustManagerFactory.init((KeyStore) null);
	TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
	if (trustManagers.length != 1 || !(trustManagers[0] instanceof X509TrustManager)) {
		throw new IllegalStateException("Unexpected default trust managers:"
				+ Arrays.toString(trustManagers));
	}
	trustManager = (X509TrustManager) trustManagers[0];


	SSLContext sslContext = SSLContext.getInstance("TLS");
	sslContext.init(null, new TrustManager[] { trustManager }, null);
	sslSocketFactory = sslContext.getSocketFactory();
} catch (GeneralSecurityException e) {
	throw new RuntimeException(e);
}

client = new OkHttpClient.Builder()
		.sslSocketFactory(sslSocketFactory, trustManager)
		.build();


Request requestOkhttp = new Request.Builder()
		.url("https://ps.pndsn.com")
		.build();

Response responseOkhttp = client.newCall(requestOkhttp).execute();
if (!responseOkhttp.isSuccessful()) throw new IOException("Unexpected code " + responseOkhttp);

This code generates the following ClientHello logs:

*** ClientHello, TLSv1
RandomCookie:  GMT: 1470746692 bytes = { 13, 37, 250, 150, 220, 1, 92, 228, 78, 1, 121, 129, 39, 94, 206, 28, 248, 18, 97, 143, 169, 18, 61, 105, 150, 84, 46, 62 }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_3DES_EDE_CBC_SHA]
Compression Methods:  { 0 }
Extension renegotiation_info, ri_length: 0, ri_connection_data: { null }
Extension server_name, server_name: [host_name: ps.pndsn.com]

The proposed protocol is TLSv1 and only one (old) cipher in present in the list: because of that sometimes the SSL handshake terminates with error when the called server does not support this single cipher.

But the Websphere server has full cipher suite support: in fact if we setup a connection using directly the javax.net API, the cipher list is complete.

The Java net connection code:

try {
   TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(
   		TrustManagerFactory.getDefaultAlgorithm());
   trustManagerFactory.init((KeyStore) null);
   TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
   if (trustManagers.length != 1 || !(trustManagers[0] instanceof X509TrustManager)) {
   	throw new IllegalStateException("Unexpected default trust managers:"
   			+ Arrays.toString(trustManagers));
   }
   trustManager = (X509TrustManager) trustManagers[0];
} catch (GeneralSecurityException e) {
   throw new AssertionError(); // The system has no TLS. Just give up.
}

SSLContext sslContext;
sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, new TrustManager[] { trustManager }, null);

url = new URL("https://ps.pndsn.com");

HttpsURLConnection con = (HttpsURLConnection) url.openConnection();
con.setSSLSocketFactory(sslContext.getSocketFactory());

The corresponding ClientHello logs:

*** ClientHello, TLSv1
RandomCookie: GMT: 1468749730 bytes = { 95, 206, 134, 169, 85, 159, 44, 73, 117, 200, 60, 67, 132, 132, 16, 172, 103, 107, 180, 190, 72, 136, 109, 177, 136, 182, 89, 192 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA]
Compression Methods: { 0 }
Extension renegotiation_info, ri_length: 0, ri_connection_data: { null }
Extension server_name, server_name: [host_name: ps.pndsn.com]

It seems that okhttp is not working correctly on Websphere 8.5.

These tests are based on okhttp version 3.6.0.

What kind of issue is this?

• Question. This issue tracker is not the place for questions. If you want to ask how to do something, or to understand why something isn’t working the way you expect it to, use Stack Overflow. https://stackoverflow.com/questions/tagged/okhttp

• Bug report. If you’ve found a bug, spend the time to write a failing test. Bugs with tests get fixed. Here’s an example: https://gist.github.com/swankjesse/981fcae102f513eb13ed

• Feature Request. Start by telling us what problem you’re trying to solve. Often a solution already exists! Don’t send pull requests to implement new features without first getting our support. Sometimes we leave features out on purpose to keep the project small.

[coxd]

@JakeWharton @swankjesse Adding to the request to see if you can accelerate 3.7.0 if your not already on the verge of releasing it. With the sweet32 vulnerability more and more people are removing 3DES as a supported suite on their servers - including us (IBM). I realize we apparently made a bad choice at some point to be different and unfortunately stuck with it are now suffering for it. Because Oracle still used SSL_ for older suites there have been suites available when using IBM Java until now when the last of these - the 3DES suites - are going away.

We did look into creating our own SslSocketFactory as a temporary solution with 3.6.0 but you don’t just accept the suites configured in that factory - you require overlap with your hard-coded list.

[swankjesse]

Oh interesting. We can probably fix to handle TLS_ or SSL_ prefixes