Okhttp: Okhttp crashes app with SSLException: Unable to create application data

[krishnasajja]

We were testing our app by changing the date on the device when this crash happened. I'm not sure if the crash is related to the date change or not.

Here is the crash log:

java.lang.RuntimeException: javax.net.ssl.SSLException: Unable to create application data
    at com.android.org.conscrypt.ConscryptFileDescriptorSocket.newSsl(ConscryptFileDescriptorSocket.java:161)
    at com.android.org.conscrypt.ConscryptFileDescriptorSocket.<init>(ConscryptFileDescriptorSocket.java:152)
    at com.android.org.conscrypt.OpenSSLSocketFactoryImpl.createSocket(OpenSSLSocketFactoryImpl.java:149)
    at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:230)
    at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:198)
    at okhttp3.internal.connection.RealConnection.buildConnection(RealConnection.java:174)
    at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:114)
    at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:193)
    at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:129)
    at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:98)
    at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:109)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:124)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:170)
    at okhttp3.RealCall.access$100(RealCall.java:33)
    at okhttp3.RealCall$AsyncCall.execute(RealCall.java:120)
    at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
    at java.lang.Thread.run(Thread.java:764)
Caused by: javax.net.ssl.SSLException: Unable to create application data
    at com.android.org.conscrypt.NativeCrypto.SSL_new(Native Method)
    at com.android.org.conscrypt.SslWrapper.newInstance(SslWrapper.java:58)
    at com.android.org.conscrypt.ConscryptFileDescriptorSocket.newSsl(ConscryptFileDescriptorSocket.java:159)
    ... 27 more

[JakeWharton]

The problem appears to be in Conscrypt not OkHttp and it sounds like the storage is full.

[yschimke]

@JakeWharton "storage" is full e.g. Unable to create a pipe? I assume possible also too many open file descriptors, the native logs should help.

https://github.com/google/conscrypt/blob/63e2139daf500bbfb62ddb1df186732201ce2525/common/src/jni/main/cpp/conscrypt/native_crypto.cc#L6376

https://github.com/google/conscrypt/blob/a2a2a855bd96721e7ee18da8c77f134d3efb58eb/common/src/jni/main/include/conscrypt/app_data.h#L140-L147

This looks like Conscrypt is breaking the createSocket API by throwing a RuntimeException instead of an IOException, so it's worth reporting and we should consider catching non IOExceptions here and rethrowing to avoid crashing.

However at the point you have exhausted native resources like this, arguably it's better for you app to crash and restart than continue failing forever more?

[yschimke]

Regarding the date aspect, much of the crypto world relies on accurate time, so changing the date/time substantially will cause valid certificates to be considered invalid because of the expiry or issue dates. So maybe this is causing some tight retry loop. But that is pure speculation.

[swankjesse]

No action for OkHttp to take here.

[yschimke]

@swankjesse is crashing on a observable SSL failure desired?

[swankjesse]

There’s a bunch of problems that can be caused by resource exhaustion: can’t open files, can’t allocate memory, can’t create threads.

We should be prudent to not exhaust resources ourselves: don’t leak memory, files, or threads. Make APIs where it’s clear who is responsible for releasing which resources.

But we shouldn’t attempt to recover from resource exhaustion problems. The process has become unstable and it’s soon going to exit.

I think this is a resource exhaustion bug and that the cause is external to OkHttp and our TLS library.

[AlbertSnow]

Yes, we should not recover from exhaust resources.
But if almost file descriptor is consumed by okhttp. I think there should be some strategy to avoid the case.
In our app, almost file descriptor exhaust is report from OkHttp stack.
I presume there is some reason why file descriptors consume, but socket not reuse.
So every https connect, will cause pip creation, consume file descriptor. So crash.

Hope the presume can give some help. Thank you;