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
|