889749 - weak cipher (only RC4-SHA) for FF sync for Android

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Android Sync, defect)

Description

[mitch]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

Using FF Mobile for Android (v22) on Samsung Galaxy S2 with Cyanogenmod 9 (-20121209-Nightly / Android 4.0.4) and my own Mozilla Sync Full-Server, FF Mobile Sync used just one weak cipher: RC4-SHA.

I have to enable RC4 ciphers (additionally) in my apache config, that FF Sync works.

Here is my apache config:

SSLProtocol all -SSLv2
  SSLHonorCipherOrder on
  SSLCipherSuite ALL:!LOW:!ADH:!EXPORT56:!RC2:!DES:!NULL:!eNULL:!MD5:+DHE-RSA-AES256-SHA:+DHE-DSS-AES256-SHA:+RC4

If I remove "+RC4" at the end, sync doesn't work.
SSL/TLS handshake will fail with an SSL error from my server, because the client offers only one cipher (RC4-SHA).

Here is one log entry from my apache. The request is from my android Dev.:

[02/Jul/2013:22:30:53 +0200] 192.168.2.202 TLSv1 RC4-SHA "GET /ffsync/1.1/xxxxxxxx/storage/clients?full=1 HTTP/1.1" 1200

And here from a Windows FF client:

[02/Jul/2013:22:28:17 +0200] 192.168.2.11 TLSv1 DHE-RSA-CAMELLIA256-SHA "GET /ffsync/1.1/xxxxxx/storage/tabs?newer=xxxxxxxxxxx&full=1 HTTP/1.1" 1096

Comment 1

[Nick Alexander :nalexander [he/him]]

(In reply to mitch from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101
> Firefox/22.0 (Beta/Release)
> Build ID: 20130618035212
> 
> Steps to reproduce:
> 
> Using FF Mobile for Android (v22) on Samsung Galaxy S2 with Cyanogenmod 9
> (-20121209-Nightly / Android 4.0.4) and my own Mozilla Sync Full-Server, FF
> Mobile Sync used just one weak cipher: RC4-SHA.
> 
> I have to enable RC4 ciphers (additionally) in my apache config, that FF
> Sync works.
> 
> Here is my apache config:
> 
> SSLProtocol all -SSLv2
>   SSLHonorCipherOrder on
>   SSLCipherSuite
> ALL:!LOW:!ADH:!EXPORT56:!RC2:!DES:!NULL:!eNULL:!MD5:+DHE-RSA-AES256-SHA:+DHE-
> DSS-AES256-SHA:+RC4
> 
> If I remove "+RC4" at the end, sync doesn't work.
> SSL/TLS handshake will fail with an SSL error from my server, because the
> client offers only one cipher (RC4-SHA).

Thanks for this outstanding sleuthing.  I see no policy reason to limit Android Sync to just RC4-SHA, so I will investigate what it takes to add additional ciphers to the code base.  needsinfo-ing myself as a reminder.

Comment 2

[Richard Newman [:rnewman]]

We settled on our current cipher list in Jan 2012 after a lengthy period of pain with Zeus + Android versions + consultation with infrasec, IIRC.

I don't recall whether it wasn't possible to add stronger ciphers (because Android has issues with cipher names: Bug 717691), whether there was no overlap between a certain Android version and Zeus, or something else.

By all means add stronger ciphers, but test exhaustively with different Android versions and our supported Sync service.

Adding svc-ops and people who know. Are we still on Zeus? Is Zeus still on 8.0?

Comment 3

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

replying offline to rnewman's question.

Comment 5

[Richard Newman [:rnewman]]

It *might* be enough for us to attempt to set the cipher list to something good (albeit including RC4-SHA to avoid breaking existing third-party servers), and rely on our fallback code otherwise.

If we can test that -- Sync *and* all of our other background ops -- on 2.2.2 (no later!), 2.3.4, and a 4.x, then I'm happy to call it good and ship it. My main concern is that I don't remember exactly the incompatibility that caused us to use this (sad but functional) unit intersection of cipher suites, and thus our testing must be extraordinarily thorough.

When we stop supporting SDK 8 (2.2), then we can explore altogether less hacky solutions to this problem.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

See http://op-co.de/blog/posts/android_ssl_downgrade/. I suspect the issue is related to that. I am guessing (don't have time to verify as I am on PTO) that it is possible to configure Android to enable additional cipher suites. Feel free to ping me for help.

Comment 7

[Nick Alexander :nalexander [he/him]]

Attachment: Work-around for elm only.

This is a stop-gap -- intended for elm only -- to unblock FxAccounts work.

Comment 8

[Richard Newman [:rnewman]]

Comment on attachment 820047 [details] [review]
Work-around for elm only.

Looks good. I'd even be inclined to spin a build against m-c, ask mobile QA to test it for Sync on our supported device ranges, and just ship it in 27 if all is good.

Comment 9

[Nick Alexander :nalexander [he/him]]

https://hg.mozilla.org/projects/elm/rev/589597d28687

Comment 10

[Nick Alexander :nalexander [he/him]]

I've landed a smaller version of this change in elm.  (Smaller because I took ciphersuites also enabled on desktop, which meant only adding 2 suites.)

QA, could you take an elm build and verify that Sync works on the full range of Android devices we support?  We're especially concerned about 2.2, 2.3, and 3.0.  If we get good results here, we'll land this on mozilla-central.

Comment 11

[Nick Alexander :nalexander [he/him]]

> QA, could you take an elm build and verify that Sync works on the full range
> of Android devices we support?  We're especially concerned about 2.2, 2.3,
> and 3.0.  If we get good results here, we'll land this on mozilla-central.

elm builds will be available at https://tbpl.mozilla.org/?tree=Elm&rev=589597d28687, although any later build will also work for testing.

Comment 12

[James Bonacci [:jbonacci]]

I can help with this.
Also adding Tracy and Marc...

I have no 3.x Android devices.
But I do have 2.2 and 4.x.

Comment 13

[Richard Newman [:rnewman]]

(In reply to James Bonacci [:jbonacci] from comment #12)

> I have no 3.x Android devices.

In fairness, *nobody* has 3.x Android devices -- they didn't sell well :P

(I might have 3.x on my TF-101. I'll check.)

Comment 14

[James Bonacci [:jbonacci]]

First successful sync between Android 2.2 device and desktop (very large profile) using the following build:
http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/elm-android/1382990738/
Specifically:
http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/elm-android/1382990738/fennec-27.0a1.en-US.android-arm.apk

Comment 15

[James Bonacci [:jbonacci]]

OK. This looks good to me.
Tried out several profiles, from simple to complex - bookmarks, passwords, history, tabs.
No issues came up on the desktop side or the Android side.

Comment 16

[mitch]

(In reply to James Bonacci [:jbonacci] from comment #14)
> profile) using the following build:
> http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/elm-android/
> 1382990738/
> Specifically:
> http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/elm-android/
> 1382990738/fennec-27.0a1.en-US.android-arm.apk

Hi. I've also testetd your build on my dev (see 1.post, Cyanogenmod 9 (-20121209-Nightly / Android 4.0.4)).
Looks great.

30/Oct/2013:07:10:01 +0100] 192.168.x.x TLSv1 DHE-RSA-AES128-SHA "GET /ffsync/1.1/xxxxxxxxxxxxxxxxxxxxxxxxxxx/info/collections HTTP/1.1" 174

Comment 17

[Renaud Allard]

I tried to install the build listed in comment 14, but it crashes at start on android 4.4.

Comment 18

[Richard Newman [:rnewman]]

Bug 934514 tracks the Kitkat crash.

Comment 19

[James Bonacci [:jbonacci]]

OK, that might be a 4.4 issue then. I was on < 4.4 I think.
I can retest this tomorrow.

Comment 20

[James Bonacci [:jbonacci]]

Yep. As it turns out, I was testing on 4.3.
I hesitate to flash either of them to 4.4 at the moment since I am still using 4.3 for testing.

:nalexander do you want more QA visibility here?
I can probably get a mobile QA to try this out...

Comment 21

[Renaud Allard]

I just tried the nightly fennec image from today (10 dec 2013 -> fennec-28.0a1.multi.android-arm.apk), and I still cannot sync with a server configured with FIPS compliant encryption. Did the patch make it into those nightlies?

Comment 22

[Richard Newman [:rnewman]]

(In reply to Renaud Allard from comment #21)
> Did the patch make it into those nightlies?

No. You'll see this bug change to RESOLVED FIXED, with a Target Milestone, when it lands.

Comment 23

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/589597d28687

Comment 24

[Renaud Allard]

I just tested nightly 29.0a1 and I confirm it synced correctly from a server without RC4 support.

Comment 25

[James Bonacci [:jbonacci]]

Sounds like we are all good then.
I will skip my testing based on Comment 24.

Comment 27

[tehownt]

The patch only adds support for two more CBC ciphersuites under TLS 1.0.

The correct patch would be acceptance of all the cipher suites FF already supports, especially the ones from TLS 1.2 suite B (RFC5288/RFC5289), TLS_(EC)DHE_(ECDSA|RSA)_WITH_AES_(128|256)_GCM_SHA(256|384).

Using this https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher as an example, it's clear that CBC cipher suites using TLS 1.0 are not enough for an acceptable security level.

Please consider adding support for those before marking this as "resolved".

Comment 28

[Richard Newman [:rnewman]]

N.B., this really isn't anything to do with Firefox in the traditional sense: it's about Android and its interaction with Sync servers. What Gecko supports doesn't have any bearing.

Bug 717691 is no longer relevant as of Firefox 31, because we no longer support SDK 8. That might mean we can simply omit cipher specifications altogether, or specify a better set, and rely on the server to do the right thing.

That's a follow-up bug, though, which I'll file.