SSL Ciphers in Android Gingerbread

hunderteins · Oct 17, 2013

************ UPDATE *****************
update.zip flashable for DSC and DSC PDroid can be found at
openssl 1.0.1e update for DSC/407
*****************************************

Hello,

you may have heard of the badly choosen default ssl ciphers (1) in gingerbread.
Gingerbread devices use outdated encryption algorithms for ssl communication.

That problem effects also gingerbread based roms like 407 or dsc. You can check this by sending
your default browser (or for example nakedbrowser) to a ssl browser test-server (2)

You will get a result like in attachment 1 ciphers_original: We are using the RC4-SHA without perfect forward secrecy. That is problematic cause of the Lucky 13 attack agains this encryption (3)

With some patch in core.jar in our framework (attachment ciphers_reorder.patch) I got DHE-RSA-AES128-SHA which is considered more secure and also supports perfect forward secrecy. (attachment ciphers_pfs)

You can get my core.jar from http://ge.tt/api/1/files/1MKLbUv/0/blob?download. Install it into /system/framework and rebuild your dalvik-cache.

I can't support TLSv1.1 or TLSv1.2 yet, because it would need to recompile a more recent version of libssl.so.

Users of Opera get even DHE-RSA-AES256-SHA in their connection (attachment ciphers_opera) which is considered state-of-the art cryptography. But even than, other android apps will use the badly choosen systems default. So it is a good idea even for opera
users, to update core.jar.

Can please someone confirm my findings, and install core.jar in a 407 or dsc rom and check your browser on (2)

(1) http://op-co.de/blog/posts/android_ssl_downgrade/
(2) https://cc.dcsec.uni-hannover.de/
(3) http://www.isg.rhul.ac.uk/tls/Lucky13.html

Razak RK · Oct 17, 2013

@hunderteins,
Thanks for the post.
I am on currently BB407, PCM ROM. Should I do this too?
How is it, which one to choose? Copy your given "core.jar" and paste to "/system/framework" and rebuild your dalvik-cache... OR flash " ciphers_reorder.patch" ?
Ops, sorry I don't know how to handle file.patch... how is it?

Attached are test run using Firefox and Opera.
I have also run using STOCK browser, BOAT browser, and ONE browser. Result same as you shown in your post's 1st picture.

Dell Streak | InnerSD 8GB | ExternalSD 32GB | Custom ROM

hunderteins · Oct 17, 2013

Razak RK said:
I am on currently BB407, PCM ROM. Should I do this too?

don't know pcm rom. Can you checksum your /system/framework/core.jar ?
For example

Code:

$ sha1sum /system/framework/core.jar
126bad1df158f1af179d353ecd9e781501a30c73  /system/framework/core.jar
$ md5sum /system/framework/core.jar
1b1c955e837b4413fcbeead0a54cd4b7  /system/framework/core.jar

If you get the same values as above, it's safe to copy my core.jar into
your /system/framework/ and rebuild dalvik-cache (for example with a restart).

If you have other checksum values, you would need to decompile (smali) your core.jar, apply the patch-file and compile (smali) it again and replace classes.dex in your core.jar.

Razak RK said:
Attached are test run using Firefox and Opera.
I have also run using STOCK browser, BOAT browser, and ONE browser. Result same as you shown in your post's 1st picture.

Well thank your for the confirmation. Firefox seems also immune. The others use the default android classes.

There is one thing in firefox though. It is able to use TLSv1.2 on the desktop. I wonder if this would work on the mobile version also. Go into about:config and set security.tls.version.max from 1 to 3. Reconnect to the test-server. You should see a nice 'This connection uses TLSv1.2'

Good luck,
hunderteins

sinan33 · Oct 17, 2013

Thank you Hunderteins!
How about kernel 3.0?
Are you still working on it?

Regards...

Razak RK · Oct 17, 2013

hunderteins said:
don't know pcm rom. Can you checksum your /system/framework/core.jar ?
For example

Code:

$ sha1sum /system/framework/core.jar 126bad1df158f1af179d353ecd9e781501a30c73 /system/framework/core.jar $ md5sum /system/framework/core.jar 1b1c955e837b4413fcbeead0a54cd4b7 /system/framework/core.jar

If you get the same values as above, it's safe to copy my core.jar into
your /system/framework/ and rebuild dalvik-cache (for example with a restart).

If you have other checksum values, you would need to decompile (smali) your core.jar, apply the patch-file and compile (smali) it again and replace classes.dex in your core.jar.

Well thank your for the confirmation. Firefox seems also immune. The others use the default android classes.

There is one thing in firefox though. It is able to use TLSv1.2 on the desktop. I wonder if this would work on the mobile version also. Go into about:config and set security.tls.version.max from 1 to 3. Reconnect to the test-server. You should see a nice 'This connection uses TLSv1.2'

Good luck,
hunderteins

~•~•~•~•~
@hunderteins,
Thank you for your reply.
Here is the checksum I get when I run in Terminal Emulator:-

$ export PATH=/data/local/bin:$PATH
$sha1sum /system/framework/core.jar
1291fcce44f4be036e2209ccb46d3313b65bdfdc /system/framework/core.jar
$md5sum /system/framework/core.jar
19bd48b8eac1bb123a823d039415a344 /system/framework/core.jar
$

So, they are NOT the same.
I don't have knowledge of how to decompile (smali) of core.jar, applying the patch-file, compile (smali) it again and replace classes.dex in my core.jar. Nope... I'm stuck to go further.

As for Firefox mobile on my Streak PCM7, I have check the menu and settings, here is NO option as per you mention.

Reason I'm interested to know is to set my Streak at best.
BTW, I'm currently installing and testing all the Streak Custom ROMs in XDA, trying to find a ROM that would probably best for my daily use = Performance+Save Power+Other Features. I probably end up having to learn to mix some ROMs into my own personal use...if I got the time to do it though...

Dell Streak | InnerSD 8GB | ExternalSD 32GB | Custom ROM

hunderteins · Oct 18, 2013

Razak RK said:
I don't have knowledge of how to decompile (smali) of core.jar, applying the patch-file, compile (smali) it again and replace classes.dex in my core.jar. Nope... I'm stuck to go further.

basically you need http://code.google.com/p/smali/downloads/list

a good tutorial how the framework is decompiled/updated can be found at
http://xdaforums.com/showthread.php?t=1084850

for how to apply a patch to a source-file consult the manpage of patch

back to topic. I updated core.jar http://ge.tt/api/1/files/7F3UKbv/0/blob?download
Now DHE-RSA-AES256-SHA is included in the list of useable ciphers.
This way in stockbrowser/nakedbrowser the same encrpytion is used as in opera/firefox
look into attached image.

Patch is also included for thoose who find it useful.

Have a nice weekend,
hunderteins

hunderteins · Oct 18, 2013

sinan33 said:
How about kernel 3.0?
Are you still working on it?

didn't post in that thread, did I?

sinan33 · Oct 19, 2013

hunderteins said:
didn't post in that thread, did I?

Sorry dude; just eagerness

Strephon Alkhalikoi · Oct 19, 2013

Confirmed working on Traveller DSC. ROM updates will be coming shortly.

Flashable zip for core.jar patch suitable for DSC and Traveller DSC: MediaFire | Mega

hunderteins · Nov 5, 2013

Elliptic curve Diffie–Hellman Key exchange

Hello,
the libssl 1.0.0a on the streak supports elliptic curve Diffie–Hellman key exchange.
With the right server, this speeds up https compared to normal Diffie–Hellman key exchange.
So I had to change the core.jar again to support these cyphers.
With this update I removed the know weak ciphers (export, 56bit etc)
I attached a openssl command for the commandline, to check libssl.so for features. It might
be useful elsewhere.

Have fun,
hunderteins

hunderteins · Nov 5, 2013

TLSv1.1 and TLSv1.2 protocol

Hello,
SSLv3/TLSv1.0 are known to be problematic with stream ciphers (the cbc ones) and
as mentioned before, I had to compiled a more recent version of libssl to support
the modern TLS variants.

Attached are the openssl binary and the libssl.so and libcrypto.so of openssl 1.0.1e.
They work on my streak and I get a clean https TLSv1.2 connection to the testserver.

Next step is, to modify core.jar again to get the modern GCM streaming methods
and SHA384 hashes.

Have a nice evening,
hunderteins

hunderteins · Nov 7, 2013

GCM streaming, sha384 hashes and server name indication (SNI)

Hello,

as mentioned before, I modified core.jar to match the ciphers from libssl 1.01e. So we get modern ciphers like ECDHE-RSA-AES256-GCM-SHA384 which are considered strong cryptographie. That's even more recent than Android 4.4 KitKat.

But Android Gingerbread has another serious flaw: SNI (server name indication) is not supported with Apache Http Client. Google fixed this *tada* in Honeycomb.
I looked into that problem, but we have to change framework.jar for that, too.

I attached the patches against the backsmalied core.jar and framework.jar. Together with openssl 1.0.1e I get a very beautiful https connection to the testservers (attached screenshots): ECDHE-RSA-AES256-GCM-SHA384 with TLS V1.2 and SNI - in stock android 2.3 browser.

Please confirm my findings. I'll try to make an streakmod compatible update.zip to spread that little security to the masses. If you point me to your core.jar/framework.jar I will consider to integrate your rom into that update.zip.

Have fun,
hunderteins

Strephon Alkhalikoi · Nov 7, 2013

So if I understand how you put the update.zip together, the update patches the files rather than simply copying a new version of the file over the existing one?

BTW, the PDroid version is working perfectly.

hunderteins · Nov 8, 2013

Strephon Alkhalikoi said:
So if I understand how you put the update.zip together, the update patches the files rather than simply copying a new version of the file over the existing one?

BTW, the PDroid version is working perfectly.

Thank you for your feedback.

Update.zip deploys openssl 1.0.1e into /system/lib and /system/bin. It replaces classes.dex inside framework.jar and core.jar when the sha1_check is correct. That is mostly like replacing the files itself, because classes.dex is the main ingredient.

An elegant way would be to baksmali/smali on the device itself, but that didn't work because of memory constraint.

have fun,
hunderteins

hunderteins · Apr 8, 2014

openssl 1.0.1g for android 2.3

Hello,
you may have heard of the heartbleed bug [1] before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected. So I made an updated package and attached it. Just put the files into your /system/bin and /system/lib and reboot.

Good luck,
hunderteins

[1] http://heartbleed.com/

Strephon Alkhalikoi · Apr 8, 2014

hunderteins said:
Hello,
you may have heard of the heartbleed bug [1] before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected. So I made an updated package and attached it. Just put the files into your /system/bin and /system/lib and reboot.

Good luck,
hunderteins

[1] http://heartbleed.com/

I'll make a flashable zip for this shortly as well as release an update to Traveller DSC.

hunderteins · Apr 10, 2014

hunderteins said:
you may have heard of the heartbleed bug before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected.

I stand corrected. The 1.0.1e version was build with -DOPENSSL_NO_HEARTBEATS. So it was not affected at all. Tested it with the stock browser and naked browser against pacemaker [1].

Anyway, 1.0.1g is not affected, too.

warning: Stock browser on Android 4.1.1 is affected.

[1] https://github.com/Lekensteyn/pacemaker

Strephon Alkhalikoi · Apr 11, 2014

Regardless, the upgrade to 1.01g should improve performance slightly, shouldn't it?

hunderteins · Apr 11, 2014

Strephon Alkhalikoi said:
Regardless, the upgrade to 1.01g should improve performance slightly, shouldn't it?

I don't think so. As of today in 1.0.1-versions of openssl there are only bugfixes. New, improved features are in 1.0.2. [1]
The changelog between 1.0.1e and 1.0.1g shows detailed bugfixes:

Code:

 Changes between 1.0.1f and 1.0.1g [7 Apr 2014]

  *) A missing bounds check in the handling of the TLS heartbeat extension
     can be used to reveal up to 64k of memory to a connected client or
     server.

     Thanks for Neel Mehta of Google Security for discovering this bug and to
     Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
     preparing the fix (CVE-2014-0160)
     [Adam Langley, Bodo Moeller]

  *) Fix for the attack described in the paper "Recovering OpenSSL
     ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
     by Yuval Yarom and Naomi Benger. Details can be obtained from:
     http://eprint.iacr.org/2014/140

     Thanks to Yuval Yarom and Naomi Benger for discovering this
     flaw and to Yuval Yarom for supplying a fix (CVE-2014-0076)
     [Yuval Yarom and Naomi Benger]

  *) TLS pad extension: draft-agl-tls-padding-03

     Workaround for the "TLS hang bug" (see FAQ and PR#2771): if the
     TLS client Hello record length value would otherwise be > 255 and
     less that 512 pad with a dummy extension containing zeroes so it
     is at least 512 bytes long.

     [Adam Langley, Steve Henson]

 Changes between 1.0.1e and 1.0.1f [6 Jan 2014]

  *) Fix for TLS record tampering bug. A carefully crafted invalid 
     handshake could crash OpenSSL with a NULL pointer exception.
     Thanks to Anton Johansson for reporting this issues.
     (CVE-2013-4353)

  *) Keep original DTLS digest and encryption contexts in retransmission
     structures so we can use the previous session parameters if they need
     to be resent. (CVE-2013-6450)
     [Steve Henson]

  *) Add option SSL_OP_SAFARI_ECDHE_ECDSA_BUG (part of SSL_OP_ALL) which
     avoids preferring ECDHE-ECDSA ciphers when the client appears to be
     Safari on OS X.  Safari on OS X 10.8..10.8.3 advertises support for
     several ECDHE-ECDSA ciphers, but fails to negotiate them.  The bug
     is fixed in OS X 10.8.4, but Apple have ruled out both hot fixing
     10.8..10.8.3 and forcing users to upgrade to 10.8.4 or newer.
     [Rob Stradling, Adam Langley]

It is sad, that on regular android devices, these bugfixes never see the light. Basically you can take these known bugs and rig most of the android 4.x devices.

reg. hunderteins

[1] http://www.openssl.org/news/changelog.html

Strephon Alkhalikoi · Apr 11, 2014

Regardless, it's not a bad thing to have the latest version.

SSL Ciphers in Android Gingerbread

Senior Member

Attachments

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Attachments

Senior Member

Attachments

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts