04-23 17:17:38.434 21599-21956/ D/NativeCrypto: ssl=0x0 NativeCrypto_SSL_interrupt
04-23 17:17:38.435 21599-21956/ D/OkHttp: <-- HTTP FAILED: javax.net.ssl.SSLHandsha
I ran into this issue when upgrading to OkHttp 4.x. Rather than having to keep track of all known TLS versions and all known ciphers as Anker recommends, use OkHttp's allEnabledTlsVersions and allEnabledCipherSuites methods:
val builder = OkHttpClient.Builder()
…
// The default OkHttp configuration does not support older versions of TLS,
// or all cipher suites. Make our support as reasonably broad as possible.
builder.connectionSpecs(listOf(ConnectionSpec.CLEARTEXT,
ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
.allEnabledTlsVersions()
.allEnabledCipherSuites()
.build()))
…
val okHttpClient = builder.build()
These lists will stay current as long as you upgrade OkHttp regularly. From the ConnectionSpec API doc:
Use Builder.allEnabledTlsVersions and Builder.allEnabledCipherSuites to defer all feature selection to the underlying SSL socket.
The configuration of each spec changes with each OkHttp release. This is annoying: upgrading your OkHttp library can break connectivity to certain web servers! But it’s a necessary annoyance because the TLS ecosystem is dynamic and staying up to date is necessary to stay secure. See OkHttp’s TLS Configuration History to track these changes.
So I solved it by adding the following to my http client object
ConnectionSpec spec = new ConnectionSpec.Builder(ConnectionSpec.COMPATIBLE_TLS)
.tlsVersions(TlsVersion.TLS_1_2, TlsVersion.TLS_1_1, TlsVersion.TLS_1_0)
.cipherSuites(
CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
CipherSuite.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA)
.build();
httpClient.connectionSpecs(Collections.singletonList(spec))
reference : https://github.com/square/okhttp/issues/3894