IssueTracker

Other information provided:

And seems like it related to sslcache and need user to clear cache file manually to recover this problem.

The symptom we met looks like socket can’t connect successfully to server if handshake is doing with TLSv1.0.
It looks if server choose TLSv1.0 to do handshake, device will not handle it and reset the connection.

If server choose TLSv1.2 , the connection will establish.
Because there is SSLHandshakeException thrown, but we are not sure whether it is normal for this case or openSSL should handle the fallback to try again.
 
Currently, our mail team can’t reproduce this issue so we are still monitor it.

Is this using Microsoft Exchange on a Windows server without MS14-066 v2 applied? The first patch causes some TLS incompatibility problems and the second revision of the patch is supposed to fix those.

sorry that I don't have the server side information.
I can 100% reproduce similar issue of SSLHandshakeException on Nexus4 with 5.0.1.
the same apk can run on Nexus4_KK with no SSLHandshakeException.
attachment is the sample app, source code and pcap file.
and below is log capturing from Nexus4 with 5.0.1

12-30 21:07:39.871 W/System.err( 4171): javax.net.ssl.SSLHandshakeException: Handshake failed
12-30 21:07:39.871 W/System.err( 4171):         at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:374)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.Connection.upgradeToTls(Connection.java:197)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.Connection.connect(Connection.java:151)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:276)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:211)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:373)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.internal.http.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:106)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.internal.http.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:208)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.internal.http.DelegatingHttpsURLConnection.getOutputStream(DelegatingHttpsURLConnection.java:218)
12-30 21:07:39.872 W/System.err( 4171):         at com.android.okhttp.internal.http.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:25)
12-30 21:07:39.873 W/System.err( 4171):         at com.htc.httpconnectiontest.SoapTransport$SoapServiceConnection.openOutputStream(SoapTransport.java:92)
12-30 21:07:39.873 W/System.err( 4171):         at com.htc.httpconnectiontest.SoapTransport.call(SoapTransport.java:183)
12-30 21:07:39.873 W/System.err( 4171):         at com.htc.httpconnectiontest.SoapTransport.call(SoapTransport.java:148)
12-30 21:07:39.873 W/System.err( 4171):         at org.ksoap2.transport.Transport.call(Transport.java:208)
12-30 21:07:39.873 W/System.err( 4171):         at com.htc.httpconnectiontest.ConnectionService.onHandleIntent(ConnectionService.java:64)
12-30 21:07:39.873 W/System.err( 4171):         at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
12-30 21:07:39.873 W/System.err( 4171):         at android.os.Handler.dispatchMessage(Handler.java:102)
12-30 21:07:39.873 W/System.err( 4171):         at android.os.Looper.loop(Looper.java:135)
12-30 21:07:39.874 W/System.err( 4171):         at android.os.HandlerThread.run(HandlerThread.java:61)
12-30 21:07:39.874 W/System.err( 4171): Caused by: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0xb91f3df0: Failure in SSL library, usually a protocol error
12-30 21:07:39.874 W/System.err( 4171): error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol (external/openssl/ssl/s23_clnt.c:735 0xace1ae61:0x00000000)
12-30 21:07:39.874 W/System.err( 4171):         at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
12-30 21:07:39.874 W/System.err( 4171):         at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:302)

update more information.
By adding log in SSL23_GET_SERVER_HELLO(), Handshake fail is due to p[2] = 1 and options = 9d1a4bff.
SSL is set to allow only SSLv3.
It seems caused by okhttp.

com.android.org.conscrypt.OpenSSLSocketImpl.setEnabledProtocols(OpenSSLSocketImpl.java:837)
com.android.okhttp.internal.Platform.supportTlsIntolerantServer(Platform.java:93)
com.android.okhttp.Connection.upgradeToTls(Connection.java:177)

More information:

With HttpURLConnection on L, you will see an SSLv3-only connection attempt after the initial connection attempt has failed. The interesting thing is the initial failure.

I built and debugged the application you attached. The first connection attempt (which includes protocols SSLv3, TLSv1, TLSv1.1 and TLSv1.2) is failing with an exception:

javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0xa0632e00: Failure in SSL library, usually a protocol error
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure (external/openssl/ssl/s23_clnt.c:762 0xac1a1e61:0x00000000)

No idea why it is mentioning SSLv3, but I assume it's because it has tried all of the better ones and negotiated down.

The SSLParameters being used on the client are:

Enabled cipher suites:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_RC4_128_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Protocols:
SSLv3
TLSv1
TLSv1.1
TLSv1.2

I created a simple test class to repeat. Interestingly, when I use a custom SSLSocketFactory and modify the socket:

      socket.setEnabledCipherSuites(socket.getSupportedCipherSuites());

it successfully handshakes. You must not do this as a solution, but it explains why it broke with L: as I understand things, various broken cipher suites have been disabled by default. They're still supported, but I believe they were disabled for a reason.

When I successfully connect, it is negotiating:

TLSv1
SSL_RSA_WITH_RC4_128_MD5

This cipher suite is not in the default set for L (see above).

More information on what ciphers are supported + Android versions here: http://developer.android.com/reference/javax/net/ssl/SSLSocket.html

Yes, it should be a Cipher not-supported problem.
The server accepts only legacy Ciphers, which are not default-enabled after 5.0

After using a custom SSLSocketFactory to setEnabledCipherSuites(new String[]{"RC4-MD5", "DES-CBC-SHA", "DES-CBC3-SHA"}), it successfully handshakes.

I was focused on protocol version and didn't think of it might be related to CipherSuite. It's implicit.

Finally, I found this can explain, http://developer.android.com/about/versions/android-5.0-changes.html#ssl

Thanks for the help.

How would I use this solution with OkHttp?  Would I enable Cipher Suites?

DownloadProvider has the same problem in 5.1, it's not allways occur, only some time it will be occur. if it occur, the devide must reboot....How can I fix the bug?