A DESCRIPTION OF THE PROBLEM :
See workaround in https://github.com/square/okhttp/pull/4138, most concerning is having to assume any SSLException is an exception that could mean falling back to other connection specs (ciphers, tls versions etc).
OkHttp has nuanced logic in https://github.com/square/okhttp/blob/7135628c645892faf1a48a8cff464e0ed4ad88cb/okhttp/src/main/java/okhttp3/internal/connection/ConnectionSpecSelector.java#L83-L127 to determine whether to retry with a fallback
REGRESSION : Last worked in version 10.0.1
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run tests for OkHttp on master
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected SSLProtocolException when the handshake fails, however getting more generic SSLException
ACTUAL -
HttpsURLConnection connection = (HttpsURLConnection) server.url("/").url().openConnection();
connection.setSSLSocketFactory(tlsNode.sslSocketFactory());
try {
connection.getInputStream();
fail();
} catch (SSLProtocolException expected) {
// RI response to the FAIL_HANDSHAKE
} catch (SSLHandshakeException expected) {
// Android's response to the FAIL_HANDSHAKE
+ } catch (SSLException expected) {
+ // JDK 1.9 response to the FAIL_HANDSHAKE
+ // javax.net.ssl.SSLException: Unexpected handshake message: client_hello
} catch (SocketException expected) {
// Conscrypt's response to the FAIL_HANDSHAKE
}
CUSTOMER SUBMITTED WORKAROUND :
https://github.com/square/okhttp/pull/4138
FREQUENCY : always