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
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
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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
@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
Status: RESOLVED → UNCONFIRMED
Component: Untriaged → Libraries
Product: Firefox → NSS
Resolution: WONTFIX → ---
Version: 35 Branch → trunk
(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"
Created attachment 8556893 [details] 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
We may need this to prioritize ChaCha20/Poly1305 depending on the AES-NI support.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: add a config/GUI for (power-)users to set the cipher preference/priority order → Add an ability to set the cipher preference/priority order
it seems like the easy fix for this is just to check based on platform.
(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)?
Probably more like if ARM. Eventually we will probably have ARMs with AES instructions but for now..
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
OS: Windows 8.1 → Android
Hardware: x86_64 → ARM
Summary: Add an ability to set the cipher preference/priority order → Prioritize ChaCha20/Poly1305 ciphers over AES-GCM for ARM builds
Patch at: https://codereview.appspot.com/290900043
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.
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?
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.
Filed bug 1250831.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago → 3 years ago
Resolution: --- → FIXED
Backed out for Firefox bustage, and we're too close to releasing NSS 3.23 https://hg.mozilla.org/projects/nss/rev/c603975b17e7
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 3.23 → ---
You need to log in before you can comment on or make changes to this bug.