SSLProtocolException: SSL handshake failed on Android N/7.0, missing support for elliptic curves. [37122132]

Can't Repro

Bug

NeedsInfo

Status Update

No update yet.

Description

de...@greyhound-software.com

created issue #1

Oct 5, 2016 03:20PM

Problem:

Connecting to servers through SSL may fail on Android N devices.
It may depend on the used cipher-suite or at least if elliptic curves are used to create the certificate?
Certificate was created with key = EC 384 bits / Signature algorithm = SHA256withECDSA

Android below 7 works.

Stacktrace:

javax.net.ssl.SSLHandshakeException: Handshake failed
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:429)
at cz.msebera.android.httpclient.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:535)
at cz.msebera.android.httpclient.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403)
at cz.msebera.android.httpclient.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:472)
at cz.msebera.android.httpclient.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:65)
at cz.msebera.android.httpclient.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at cz.msebera.android.httpclient.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:145)
at cz.msebera.android.httpclient.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131)
at cz.msebera.android.httpclient.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at cz.msebera.android.httpclient.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at cz.msebera.android.httpclient.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:860)
at cz.msebera.android.httpclient.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at com.loopj.android.http.AsyncHttpRequest.makeRequest(AsyncHttpRequest.java:146)
at com.loopj.android.http.AsyncHttpRequest.makeRequestWithRetries(AsyncHttpRequest.java:177)
at com.loopj.android.http.AsyncHttpRequest.run(AsyncHttpRequest.java:106)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
Caused by: javax.net.ssl.SSLProtocolException: SSL handshake terminated: ssl=0x93a3f600: Failure in SSL library, usually a protocol error
error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE (external/boringssl/src/ssl/s3_pkt.c:610 0x936f69e0:0x00000001)
error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO (external/boringssl/src/ssl/s3_clnt.c:764 0xa2f6b216:0x00000000)
at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:357)
... 19 more

Further information:
-

http://stackoverflow.com/questions/39133437/sslhandshakeexception-handshake-failed-on-android-n-7-0
-

https://code.google.com/p/android/issues/detail?id=218119

Comments

de...@greyhound-software.com <de...@greyhound-software.com> #2Oct 5, 2016 04:10PM

Minimum code to reproduce (I found no other server useing elliptic curves for their certificate):

new Thread(new Runnable() {
@Override
public void run() {
try {
URL url = new URL("

https://91.190.151.169");
url.openConnection().getInputStream(); // javax.net.ssl.SSLHandshakeException: Handshake failed
} catch (java.io.IOException e) {
e.printStackTrace();
}
}
}).start();

jo...@joelj.org <jo...@joelj.org> #3Oct 22, 2016 03:20AM

Did you end up working out what causes this?

I have two sites (EC 384 certs, ECDHParameters and Curves set to secp384r1 only) which seemed to work fine on across all browser stacks and devices up until Android 7.

de...@greyhound-software.com <de...@greyhound-software.com> #4Oct 24, 2016 02:43PM

We hoped that this issue would be fixed sooner or later - but it seems that there is no interest besides the android team.
Removing RC4 from the cipher-suite on server-side may help - but I do not think that this is a sophisticating solution.

mu...@gmail.com <mu...@gmail.com> #5Dec 16, 2016 07:11AM

I have generated a bug report about this issue and shared it with android-bugreport@google.com

https://drive.google.com/drive/folders/0BwOTCxzXuMaNRWZ4c3hUMGdnbk0

Server-side, I use the modern cipher suite as suggested here:

https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.10.1&openssl=1.0.1e&hsts=yes&profile=modern

Certificate is EC type secp384r1.

This regression is rather painful as it would mean lowering security on servers where we try to keep it tight.

dn...@google.com <dn...@google.com> Jan 2, 2017 11:15AM

Assigned to dn...@google.com.

dn...@google.com <dn...@google.com> #6Jan 2, 2017 12:24PM

Status: New

Hi,
Can you provide the below requested information to better understand the issue:

Device used
Which device did you use to reproduce this issue?

Steps to reproduce
What steps do others need to take in order to reproduce the issue themselves?
Please explain the steps in detail.

Frequency
How frequently does this issue occur? (e.g 100% of the time, 10% of the time)

Expected output
What do you expect to occur?

Current output
What do you see instead?

Also please check the issue on android N latest build on nexus and pixel devices and let us know the result.

If issue reproduces,then please share the bugreport.

Android bug report:
After reproducing the issue, navigate to developer settings, ensure ‘USB debugging’ is enabled, then enable ‘Bug report shortcut’. To take bug report, hold the power button and select the ‘Take bug report’ option.

Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.

dn...@google.com <dn...@google.com> #7Jan 9, 2017 05:49AM

Please provide the information requested in

comment #6

to investigate this issue further.

hr...@gmail.com <hr...@gmail.com> #8Jan 9, 2017 06:19AM

(This report is using CardDav-Sync as a support to show the problem, other applications using the system's "crypto library" are affected, whereas apps that ship with their own aren't: Chrome for instance)

- Device used: OnePlus A3003 with OxygenOS version OP3_02_Open_10 (Android 7.0 security patch level 1st Dec. 2016)

- Steps to reproduce :
* Install CardDavSync (org.dmfs.carddav.sync) and connect to a server (ownCloud for instance) that uses EC certificates
* Configure the URL and credentials
* Try to save and connect, it fails.

- Frequency: 100% of the time

- Expected output: The connection test succeeds and I can use the CardDav app.
- Current output: "A Network error occured, please check your account data or try again later"

I can't check the latest N build because I don't own a Pixel or Nexus device.

Link to the Debug zipfile:

https://drive.google.com/drive/folders/0BwOTCxzXuMaNRWZ4c3hUMGdnbk0

de...@greyhound-software.com <de...@greyhound-software.com> #9Jan 9, 2017 08:33AM

The initial problem #1 seems to be solved within the latest Patch for Android N, thanks.
As we do not use CardDav I am not aware of problems regarding that.

dn...@google.com <dn...@google.com> #10Jan 10, 2017 09:25AM

We are able to reproduce this issue on nexus devices due to dependencies mentioned in reproduction steps in

comment #8

.

So please try to check this issue on nexus device on android N latest build and let us know the result.

Also as per the

comment #9

issue seems to be fixed in android N latest build.

hr...@gmail.com <hr...@gmail.com> #11Jan 10, 2017 10:33AM

Hi,

As I don't have a Pixel/Nexus device, I just gave it a try using an AVD with 7.1.1 and it works well with CardDav and a server that presents EC certificate.

So I guess this can be marked as solved.

dn...@google.com <dn...@google.com> #12Jan 10, 2017 10:48AM

Status: Won't Fix (Not Reproducible)

Thank you.

Closing this issue as per

comment #11

me...@gmail.com <me...@gmail.com> #13Apr 7, 2017 11:48AM

Some relevant discussion / workarounds:

StackOverflow:

https://stackoverflow.com/questions/39133437/ &

http://stackoverflow.com/a/42047877/
LetsEncrypt community:

https://community.letsencrypt.org/t/warning-android-7-0-clients-not-browsers-can-only-use-curve-prime256v1/23212

Short summary:
* Android 7.0 deployed in the wild has support for only one elliptic curve: secp256r1
* Android 7.1.1 (in emulator) has support for 3 curves: secp256r1, secp384r1, secp512r1
* Some "modern configuration" web services use secp384r1 (which was supported before 7), leading to unexpected failure with Android 7.0

While this may be fixed in 7.1, 7.0 has a current install share of 4.5% Android devices, and timeline for 7.1 updates is frequently uncertain - therefore, the impact is not non-negligible.

mt...@gmail.com <mt...@gmail.com> #14Apr 21, 2017 02:44AM

Ok, did around so digging and it turns out that issue mentioned above happens (in my case) only with Retrofit 2.2.0 version. Where with 2.1.0 it runs just fine (all testing at Android 7.0).
On the other hand issue was reported when 2.2.0 wasn't released yet so probably issue lies deeper than Retrofit (or author used a snapshot version).

Also I agree that issue is non-negligible and should be addressed more than "Won't Fix".
Please take a look if you used Retrofit 2.2.0 and let me know so we can find source of it.

cu...@gmail.com <cu...@gmail.com> #15Apr 25, 2017 02:20PM

This bug is reproducible. For example see: "Google Screwed Up Secp384r1 ECC Certificates" (Posted on November 25, 2016)

https://zitseng.com/archives/12787;

https://github.com/haiwen/seadroid/issues/599 (post: typingArtist commented on Nov 27, 2016) also

https://groups.google.com/forum/#!topic/k-9-mail/RqgHRs1Wh24 (my brief report in forum). If you would like to repeat this, then use any android device running 7.0 and try to connect to my IMAP server which has an secp384r1 key. The connect will fail and examination of the packet trace reveals that the android device is only offering the EC curve secp256r1. This is a regression from android 6.x and should be simple to fix.

cp...@gmail.com <cp...@gmail.com> #16Jun 15, 2017 04:29PM

This impacts "Exchange" type sync.

To reproduce:
have handset running pre 7.0 Android;
see email syncing with Exchange-type email provider using ssl where chain includes secure ecdhcurve e.g secp384r1;
update handset to 7.0;

expected result: handset continues to sync email

actual result: sync fails on ssl handshake.

dr...@gmail.com <dr...@gmail.com> #17Jun 30, 2017 03:15PM

As long as Google is supporting Android 7.0, this bug is gonna be severe for any customer even if the vendor is up-to-date on 7.0.

Marking that one as Won’t fix just because it was fixed on 7.1.1 can only be a mistake. Please re-open and fix for 7.0.

de...@greyhound-software.com <de...@greyhound-software.com> #18Jul 3, 2017 07:38AM

Vote for reopen this too!
Some vendors start shipping devices with old 7.0 and no one knows when/if those vendors will roll out 7.1.1
So some customers will now run into this problem.

dr...@gmail.com <dr...@gmail.com> #19Jul 3, 2017 10:19AM

It appears that no-one other than the OP is subscribed to that issue anymore, so there is no surprise that nobody actually takes care. We should either approach the person who closed this issue, directly or open another issue. I can only see the abbreviated email addresses, but perhaps you know the full email address. Could you please take care?

na...@gmail.com <na...@gmail.com> #20Apr 4, 2021 11:34AM

any news here?

[Deleted User] <[Deleted User]> #21Apr 6, 2021 07:58AM

#20: Using the GSM provider solved the issue for us:

https://developer.android.com/training/articles/security-gms-provider

my...@traderepublic.com <my...@traderepublic.com> #22Aug 12, 2021 11:41AM

Issue is still preset to me after I've followed instructions from

https://developer.android.com/training/articles/security-gms-provider.

1. List of providers before -> [AndroidNSSP, AndroidOpenSSL, CertPathProvider, AndroidKeyStoreBCWorkaround, BC, HarmonyJSSE, AndroidKeyStore, TimaKeyStore]

2. Log from ProviderInstaller → ProviderInstaller(29061): Installed default security provider GmsCore_OpenSSL

3. List of providers after → [GmsCore_OpenSSL, AndroidNSSP, AndroidOpenSSL, CertPathProvider, AndroidKeyStoreBCWorkaround, BC, HarmonyJSSE, AndroidKeyStore, TimaKeyStore]

Any ideas how I could solve it?

to...@googlemail.com <to...@googlemail.com> #23Jan 3, 2022 05:46PM

The issue is reproducible on Android 7.0 as documented in this issue.

ma...@gmail.com <ma...@gmail.com> #24Feb 4, 2025 08:41PM

I think this bug now occurs in Android's native IPSec/MSCHAPv2 VPN client. This is with Android 15 latest updates, on a Pixel 6 Pro.

Using a Let's Encrypt ECDSA SHA384 certificate with strongSwan server, the strongSwan Android application has no errors.

Using the built-in Android VPN client produces the following errors in logcat:

"IkeAuthDigitalSignPayload: Unexpected or repeated Signature Hash Algorithm: 5"
"android.net.ipsec.ike.exceptions.AuthenticationFailedException: Unrecognized ASN.1 objects for Signature algorithm and Hash"

vi...@google.com <vi...@google.com> #25Feb 9, 2025 12:05PM

If you are still facing the issue, please feel free to open a new issue and add the relevant information along with reference to the earlier issue. Thanks