SSL Cipher Suite Reihenfolge

[n0m3k]

Hallo,

bei der Nutzung einer SSL Verbindung besteht ja in Android die Möglichkeit die Cipher Suite manuell mit der Methode

setEnabledCipherSuites(String[])

auszuwählen. (siehe SSLSocket | Android Developers
Als Erklärung steht nur dabei:

Sets the names of the cipher suites to be enabled. Only cipher suites returned by getSupportedCipherSuites() are allowed.
suites: the names of the to be enabled cipher suites.

Mein Frage: Es gibt bei der Cipher Suite ja eine "preference order". Bvorzugte Cipher Suites des Clients in absteigender Reihenfolge.

Wenn ich die Cipher Suites im Array übergebe, werden dann die Suites in der Reihenfolge übertragen oder nicht???

Schonmal danke im voraus!

 

[missspelled]

Hallo,
ich wüsste nicht warum die Reihenfolge sich in deinem Array ändern sollte... Oder habe ich die Frage missverstanden?

 

[n0m3k]

Ne, dass denke ich auch nicht. Aber man kann nicht zu 100% sagen, ob das Array im Protokoll auch genau in der Reihenfolge auftaucht? In der Beschreibung steht ja nichts davon. Oder muss man die Beschreibung der Methode einfach zusammen mit der Spezifikation von TLS/SSL sehen?

 

[RED-BARON]

Hallo,

ich möchte meine Frage hier anschließen ...

in meinem Code finden sich folgende Zeilen

mSSLContext = SSLContext.getInstance("TLS");
mSSLContext.init(null, trustAllCerts, null); //new java.security.SecureRandom());
mSSLSocketFactory = mSSLContext.getSocketFactory();
networkSocket = (SSLSocket)mSSLSocketFactory.createSocket(networkSocket, mHost, mPort, true);
((javax.net.ssl.SSLSocket)networkSocket).addHandshakeCompletedListener(new MyHandshakeListener());
((javax.net.ssl.SSLSocket)networkSocket).startHandshake();  <= Fehler / Exception         
networkSocket.getOutputStream().flush();

Es wird ein Socket ("networkSocket") erstellt ( nicht im Codeabschnitt enthalten ) und mit Hilfe diesem ein SSL-Socket erzeugt.

Der dargestellte Code arbeitet bisher auf allen Geräten ab Android 2.2 ( ... ) bis 5.1.1 ( z.B. Sony D6503 ) die wahlfrei verwendet
wurden ohne Probleme. Mit dem Samsung S6 jedoch, wird ein Handshake-Error ausgegeben. Da ich selbst über kein S6 verfüge
und der konkrete Fehlertext erst mir zugesendet werden kann nachdem eine verschlüsselte Verbindung hergestellt werden konnte,
bin ich auf die Aussagen der Anwender angewiesen. Das verwendete Zertifikat ist selbst signiert mit 1024bit.

Auf meiner Suche nach einer möglichen Ursache fand ich: Android 5.1 Changelog is Official
Die Änderungen müssten dann aber auch in dem genannten Sony Gerät enthalten sein, welches kein Fehler meldet.

Was ist anders am Samsung S6 ? Ist überhaupt was anders ? ( herstellerspezifisches bezüglich Security )

 

[RED-BARON]

Hallo,

heute habe ich ein S6 zur Verfügung und lasse mir den Fehler protokollieren:

Error: SSLHandshakeException := Handshake failed
javax.net.ssl.SSLHandshakeException: Handshake failed
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:408)
at mysql.MySQL.login(MySQL.java:5570)
at mysql.MySQL.synchronize_0800(MySQL.java:3658)
at mysql.MySQL.run(MySQL.java:3833)
Caused by: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x7fb1896180: Failure in SSL library, usually a protocol error
error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:got Channel ID before a ccs (external/openssl/ssl/s3_clnt.c:3651 0x7fa49ab4b0:0x00000000)
at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:336)

es gibt nicht viele Treffer bei Google :/

java - How to disable SSLv3 in android for HttpsUrlConnection? - Stack Overflow

Die Fehlermeldung finde ich im SourceCode bei Google.... ist eine neue Zeile

0004-channelid.patch - gentroid - Bring Android back home to Linux. - Google Project Hosting

"+{ERR_REASON(SSL_R_GOT_CHANNEL_ID_BEFORE_A_CCS),"got Channel ID before a ccs"},"

... aber was sagt mir das genau ?

Die Website, welche mit selben Zertifikat arbeitet, kann geöffnet werden.
( mit entsprechender Meldung, unsicher - selbstsigniertes Zertifikat )


Edit: Auszüge von testssl.sh

[1;34m--> Testing protocols [m(via sockets except TLS 1.2 and SPDY/NPN)

[1m SSLv2 [m[1;32mnot offered (OK)[m
[m[1m SSLv3 [m[0;31moffered (NOT ok)[m
[1m TLS 1 [moffered
[1m TLS 1.1 [moffered
[1m TLS 1.2 [m[1;32moffered (OK)[m
[1m SPDY/NPN [mnot offered

[1;34m--> Testing ~standard cipher lists[m

[1m Null Ciphers [m[1;32mnot offered (OK)[m
[1m Anonymous NULL Ciphers [m[1;32mnot offered (OK)[m
[1m Anonymous DH Ciphers [m[1;32mnot offered (OK)[m
[1m 40 Bit encryption [m[1;32mnot offered (OK)[m
[1m 56 Bit encryption [m[0;35mLocal problem: No 56 Bit encryption configured in /usr/bin/openssl[m
[1m Export Ciphers (general) [m[1;32mnot offered (OK)[m
[1m Low (<=64 Bit) [m[1;32mnot offered (OK)[m
[1m DES Ciphers [m[1;32mnot offered (OK)[m
[1m Medium grade encryption [m[0;31moffered (NOT ok)[m
[1m Triple DES Ciphers [m[0;33moffered (NOT ok)[m
[1m High grade encryption [m[1;32moffered (OK)[m

[1m Heartbleed[m (CVE-2014-0160) [1;32mnot vulnerable (OK)[m (timed out)
[1m CCS[m (CVE-2014-0224) [1;32mnot vulnerable (OK)[m
[1m Secure Renegotiation [m(CVE-2009-3555) [1;32mnot vulnerable (OK)[m
[1m Secure Client-Initiated Renegotiation [m[0;32mnot vulnerable (OK)[m
[1m CRIME, TLS [m(CVE-2012-4929) [0;32mnot vulnerable (OK)[m
[1m BREACH[m (CVE-2013-3587) [0;31mNOT ok: uses gzip HTTP compression [m(only "/" tested)
[1m POODLE, SSL[m (CVE-2014-3566) [0;31mVULNERABLE (NOT ok)[m, uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)
[1m TLS_FALLBACK_SCSV[m (RFC 7507), experim. [0;32mDowngrade attack prevention supported (OK)[m
[1m FREAK[m (CVE-2015-0204) [1;32mnot vulnerable (OK)[m (tested with 4/9 ciphers)
[1m LOGJAM[m (CVE-2015-4000), experimental [1;32mnot vulnerable (OK)[m ([35mtested w/ 2/4 ciphers only![0;10m), common primes not checked.
[1m BEAST[m (CVE-2011-3389) SSL3:[0;33m ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA
DES-CBC3-SHA[m
TLS1:[0;33m ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA
DES-CBC3-SHA[m
-- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2
[1m RC4[m (CVE-2013-2566, CVE-2015-2808) [0;31mVULNERABLE (NOT ok): [m[0;31mECDHE-RSA-RC4-SHA [m[0;31mRC4-SHA [m

ein Hinsweis ?
[1m POODLE, SSL[m (CVE-2014-3566) [0;31mVULNERABLE (NOT ok)[m, uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)


Ich suche zwar intensiv ...
https://secure-resumption.com/tlsauth.pdf
... eine Idee für eine mögliche Ursache habe ich aber noch nicht.
Momentan kann ich auch nicht mit WireShark prüfen was die Unterschiede
während des Handshake sind. :/ Hoffe das wird mir irgendwann noch einmal möglich sein

 

[RED-BARON]

Teillösung:

das Problem tritt offenbar nur bei Samsung SM-G925F ( S6 Edge ) auf, jedoch *nicht* bei Samsung SM-G920F ( S6 )
In meiner Datenbank habe ich ein Anwender gefunden, der dieses ( Samsung SM-G920F, 5.1.1 ) erfolgreich/problemlos verwendet.