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