New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSL Error when subscribing to podcast #2245

Open
nougad opened this Issue Jan 18, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@nougad

nougad commented Jan 18, 2017

App version: 1.6.2.3 (from Google Play)

Android version: 7.0

Devide model: nexus6

Expected behaviour: subscribe works

Current behaviour: ssl error

An error occurred: IO Error
(SSL handshake aborted: ssl=0x8ab26b80: I/O error during system call, Connection reset by peer)

Steps to reproduce:

  1. try to subscribe: https://requestforcomments.de/feed/mp3

Stacktrace/Logcat:

01-18 23:44:59.250 10764 11956 W System.err: javax.net.ssl.SSLHandshakeException: SSL handshake aborted: ssl=0x8845b280: I/O error during system call, Connection reset by peer
01-18 23:44:59.275 10764 11956 W System.err: 	at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:357)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.internal.io.RealConnection.connectTls(RealConnection.java:192)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.internal.io.RealConnection.connect(RealConnection.java:4149)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.internal.http.StreamAllocation.findConnection(StreamAllocation.java:184)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.internal.http.StreamAllocation.findHealthyConnection(StreamAllocation.java:126)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.internal.http.StreamAllocation.newStream(StreamAllocation.java:95)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.Call.getResponse(Call.java:23281)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:243)
01-18 23:44:59.275 10764 11956 W System.err: 	at de.danoeh.antennapod.core.service.download.HttpDownloader$BasicAuthorizationInterceptor.intercept(HttpDownloader.java:325)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:232)
01-18 23:44:59.275 10764 11956 W System.err: 	at com.squareup.okhttp.Call.execute(Call.java:3205)
01-18 23:44:59.275 10764 11956 W System.err: 	at de.danoeh.antennapod.core.service.download.HttpDownloader.download(HttpDownloader.java:102)
01-18 23:44:59.275 10764 11956 W System.err: 	at de.danoeh.antennapod.core.service.download.Downloader.call(Downloader.java:43)
01-18 23:44:59.275 10764 11956 W System.err: 	at de.danoeh.antennapod.activity.OnlineFeedViewActivity$2.call(OnlineFeedViewActivity.java:1273)
01-18 23:44:59.275 10764 11956 W System.err: 	at rx.Observable.unsafeSubscribe$639a3d1a(Observable.java:9861)
01-18 23:44:59.275 10764 11956 W System.err: 	at rx.internal.operators.OperatorSubscribeOn$1.call(OperatorSubscribeOn.java:94)
01-18 23:44:59.276 10764 11956 W System.err: 	at rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:55)
01-18 23:44:59.276 10764 11956 W System.err: 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428)
01-18 23:44:59.276 10764 11956 W System.err: 	at java.util.concurrent.FutureTask.run(FutureTask.java:237)
01-18 23:44:59.276 10764 11956 W System.err: 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:272)
01-18 23:44:59.276 10764 11956 W System.err: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
01-18 23:44:59.276 10764 11956 W System.err: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
01-18 23:44:59.276 10764 11956 W System.err: 	at java.lang.Thread.run(Thread.java:761)
01-18 23:44:59.276 10764 11956 W System.err: 	Suppressed: javax.net.ssl.SSLHandshakeException: Handshake failed
01-18 23:44:59.276 10764 11956 W System.err: 		at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:429)
01-18 23:44:59.276 10764 11956 W System.err: 		... 22 more
01-18 23:44:59.276 10764 11956 W System.err: 	Caused by: javax.net.ssl.SSLProtocolException: SSL handshake terminated: ssl=0x8845b280: Failure in SSL library, usually a protocol error
01-18 23:44:59.276 10764 11956 W System.err: error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE (external/boringssl/src/ssl/s3_pkt.c:610 0x89cc7120:0x00000001)
01-18 23:44:59.276 10764 11956 W System.err: error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO (external/boringssl/src/ssl/s3_clnt.c:764 0x9d4af91a:0x00000000)
01-18 23:44:59.276 10764 11956 W System.err: 		at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
01-18 23:44:59.276 10764 11956 W System.err: 		at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:357)
01-18 23:44:59.277 10764 11956 W System.err: 		... 22 more

It looks like boringssl has problems with TLS 1.2??

$ nmap --script ssl-enum-ciphers -p 443 requestforcomments.de

Starting Nmap 7.40 ( https://nmap.org ) at 2017-01-18 23:41 CET
Nmap scan report for requestforcomments.de (138.201.121.149)
Host is up (0.083s latency).
Other addresses for requestforcomments.de (not scanned): 2a01:4f8:172:24d4:1::100
rDNS record for 138.201.121.149: mail.molkentin.net
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp384r1) - A
|     compressors: 
|       NULL
|     cipher preference: server
|_  least strength: A

chrome on same phone opens url without problems

@mfietz

This comment has been minimized.

Show comment
Hide comment
@mfietz

mfietz Jan 19, 2017

Contributor

Works fine on my phone also running Android 7.

Contributor

mfietz commented Jan 19, 2017

Works fine on my phone also running Android 7.

@davidmehren

This comment has been minimized.

Show comment
Hide comment
@davidmehren

davidmehren Feb 11, 2017

I have the same error on a OnePlus 3T with Android 7.0.
I noticed that the server sends two certificates, one of them for the wrong domain. That might confuse boringssl (but that would be a bug, I suppose): https://www.ssllabs.com/ssltest/analyze.html?d=requestforcomments.de&s=138.201.121.149
BeyondPod also refuses to connect to that server, but Pocket Casts works. They probably use some other http(s) client config.

davidmehren commented Feb 11, 2017

I have the same error on a OnePlus 3T with Android 7.0.
I noticed that the server sends two certificates, one of them for the wrong domain. That might confuse boringssl (but that would be a bug, I suppose): https://www.ssllabs.com/ssltest/analyze.html?d=requestforcomments.de&s=138.201.121.149
BeyondPod also refuses to connect to that server, but Pocket Casts works. They probably use some other http(s) client config.

@mhellwig

This comment has been minimized.

Show comment
Hide comment
@mhellwig

mhellwig May 19, 2017

according to comments on one of the recent episodes of this podcast, the problem lies with Android 7.0:
https://community.letsencrypt.org/t/warning-android-7-0-clients-not-browsers-can-only-use-curve-prime256v1/23212
i.e. "It appears that there is a regression in Android 7.0 (said to be fixed in 7.1.1 at least) where the only elliptic curve available from the system TLS stack is prime256v1". Browsers are not affected because they bring their own tls stack.
So .. since there are going to be a number of phones that have 7.0 but won't see an update to 7.1.1 soon or ever, is there a way to fix this within the app?
that podcast uses a prime384 curve and according to the server administrator "a tls downgrade is not gonna happen".

mhellwig commented May 19, 2017

according to comments on one of the recent episodes of this podcast, the problem lies with Android 7.0:
https://community.letsencrypt.org/t/warning-android-7-0-clients-not-browsers-can-only-use-curve-prime256v1/23212
i.e. "It appears that there is a regression in Android 7.0 (said to be fixed in 7.1.1 at least) where the only elliptic curve available from the system TLS stack is prime256v1". Browsers are not affected because they bring their own tls stack.
So .. since there are going to be a number of phones that have 7.0 but won't see an update to 7.1.1 soon or ever, is there a way to fix this within the app?
that podcast uses a prime384 curve and according to the server administrator "a tls downgrade is not gonna happen".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment