1126830 - Prioritize ChaCha20/Poly1305 ciphers over AES-GCM for ARM builds

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P3)

Description

[Ralf Hauser]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150122214805

Steps to reproduce:

Thomas Peters makes a good point in bug 1037098 comment 3 : if firefox is my secure browser of choice, I want to be able to access sites with the cipher of my preference in a zero day situation. Sure, the masses will not reconfigure their preferences, but I don't want to be forced use MSIE (https://code.google.com/p/chromium/issues/detail?id=58833#c1) or have to wait until a firefox patch-release. 
Also, throwing out relatively weak / rarely used ciphers (e.g. 112 bit TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA as per bug 1036765) is also detrimental to my ability to use firefox in the hopefully never happening case we would find out AES is broken - then I would want this alternative to be still available and be able to make it the only/top priority / preference for my firefox's handshake - it is certainly better than having no encryption anymore ...



Expected results:

see also https://code.google.com/p/chromium/issues/detail?id=442572 , bug 949564 , https://code.google.com/p/chromium/issues/detail?id=58831

Comment 1

[Ralf Hauser]

as for removing ciphers that are rarely used or sub-standard quality. I guess we might learn from agricultre. Just farming the best growing cow species increases the risk of a famine.
It is better to have a variety of species to have a bigger gene pool - more robust to sudden diseases or parasites - https://www.prospecierara.ch/fr

Comment 2

[Masatoshi Kimura [:emk]]

Many servers ignore Client's preference. if by any chance AES is broken, preference change will be of little help. You will have to disable all AES cipher suites which is already possible (Go to about:config and type "ssl3" into the search box).

NSS does not support changing the preference order. We need to add a function to control the preference if we implement this in Firefox. But I'm not sure this deserves to add complexity to our code base in the first place. People are already shooting their foot by using the "security.ssl3." preferences (see bug 1121706). I'm not sure it's a good idea to add yet another footgun.

Comment 3

[Justin Dolske [:Dolske]]

There's no way we'd ship UI like this in Firefox. Way too technical, and of extremely narrow interest. It might be a fair request to allow adding the capability to NSS so that an addon could implement such UI. I'm still dubious about the value, though.

Comment 4

[Ralf Hauser]

@masatoshi: I don't understand you statement re servers ignoring client preferences. IFAICR as per the TLS standards, the server offers the ciphers it is willing to work with and the client picks one of them. So, the server will never learn about the client preference, it just sees *one* of the offered ciphers picked ?!?

@Justin: fine, then let's move it to NSS

Comment 5

[Ryan Sleevi]

(In reply to Ralf Hauser from comment #4)
> @masatoshi: I don't understand you statement re servers ignoring client
> preferences. IFAICR as per the TLS standards, the server offers the ciphers
> it is willing to work with and the client picks one of them. So, the server
> will never learn about the client preference, it just sees *one* of the
> offered ciphers picked ?!?

No, that's not how TLS works. See RFC 5246 or https://technet.microsoft.com/en-us/library/cc785811%28v=ws.10%29.aspx for a more visual diagram of this.

The client hello says all of which the client supports, in order of preference. The server hello selects from this. It may choose to use the client's preferences in consideration, or it may not. Many (most?) servers ignore client preference, as explained in Comment 2.

I agree with dolske - seems like a WontFix. NSS should be "secure by default"

Comment 6

[Ralf Hauser]

Attachment: Thanks to Ryan for the clarification. Do you think that allowing to change the preference is detrimental to 'NSS should be "secure by default"'? the attached shows the "ssl3" search in about:config

Comment 7

[Masatoshi Kimura [:emk]]

We may need this to prioritize ChaCha20/Poly1305 depending on the AES-NI support.

Comment 8

[Eric Rescorla (:ekr)]

it seems like the easy fix for this is just to check based on
platform.

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Eric Rescorla (:ekr) from comment #8)
> it seems like the easy fix for this is just to check based on
> platform.

You mean should we should just bake this into NSS and move ChaCha higher up if defined(ANDROID)?

Comment 10

[Eric Rescorla (:ekr)]

Probably more like if ARM.

Eventually we will probably have ARMs with AES instructions but for now..

Comment 11

[Tim Taubert [:ttaubert] (inactive)]

Patch at: https://codereview.appspot.com/290900043

Comment 12

[Martin Thomson [:mt:]]

This is probably OK; but it doesn't address the case where you have an ARM client and you want to respect its choice.  This should do though.

Comment 13

[Tim Taubert [:ttaubert] (inactive)]

Good point, I think we can do this as a follow-up. There aren't a lot of NSS servers out there except for WebRTC. Or am I missing something?

Comment 14

[Martin Thomson [:mt:]]

Yes, that's why you get an r+.  I think that we should respect client preference for these cipher suites, but that is considerably more work to get right.  I think that you would need a new suite selection algorithm.  If you wouldn't mind opening a bug on that, that would be good.

Comment 15

[Tim Taubert [:ttaubert] (inactive)]

Filed bug 1250831.

Comment 16

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/projects/nss/rev/e7feee58d6e2

Comment 17

[Kai Engert (:KaiE:)]

Backed out for Firefox bustage, and we're too close to releasing NSS 3.23
https://hg.mozilla.org/projects/nss/rev/c603975b17e7

Comment 18

[Benjamin Beurdouche [:beurdouche]]

Chacha20Poly1305 is the default if AES-NI is not available on ARM.
https://searchfox.org/mozilla-central/source/security/manager/ssl/nsNSSIOLayer.cpp#2736