Closed Bug 1074130 Opened 10 years ago Closed 10 years ago

RFE (RFC): don't offer weak but widespread cipher suites in ClientHello, enable them in second ClientHello if first fails with No Cipher Overlap

Categories

(NSS :: Libraries, defect)

3.16.2
x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jasa.david, Unassigned)

Details

These days, many servers still do choose RC4 or 3DES cipher suites in spite of both client and server knowing better. It would therefore make sense to try first sending a ClientHello with these obsolete-but-widely-used-and-sometimes-required cipher suited omitted for security and only if this ClientHello fails with No Cipher Overlap, send another ClientHello with these ciphers turned on. I'm not sure however if the proposal fits with expectations that apps on top of NSS library have so please take this as a kind of RFC how the problem may be tackled better. I'm also reporting against NSS and not Firefox as there are quite some apps that actually use NSS that would benefit and it's not practical do code such a behaviour into each and every one of them. Effectively, this RFE calls for creation of some list of "obsolete but usable" ciphers - cipher suites that should be avoided if possible but with automatic fall back to them if no better options are available. These ciphers are currently RC4, 3DES and probably some might put AES-256 to the list. Version: I'm running nss 3.16 How to test =========== 1. set up two https servers: A) with better cipher support but always picking RC4 B) just with RC4 support 2. connect with nss-based client to these servers Expected results: A) client connects using something better than RC4 B) client connects Actual results: based on client settings (e.g. ssl.*rc4* in about:config of firefox), either of these happens: 1. A) client connects with RC4 (bad: should be avoided) B) client connects (good) 2. A) client connects with good cipher suite (good) B) client doesn't connect (bad)
The non-secure fallback is not something the NSS library would implement. The application (Firefox) already implemented RC4 fallback in bug 1088915. In general, non-browser apps should never implement such fallback dance. Unlike RC4, no one would be motivated to prefer 3DES over AES. Some websites insist RC4 because it is faster than other cipher suites even if AES-NI is available. This is not applicable to 3DES at all. 3DES is slower than AES even if AES-NI is unavailable. Another reason is that RC4 is a stream cipher which is immune to BEAST, Lucky 13, POODLE, etc. Again, it is not applicable to 3DES. 3DES is a block cipher, so any CBC mode vulnerabilities would be equally applicable to AES and 3DES. So there is little point to hide 3DES behind the fallback. We should reduce reliance on the non-secure fallback rather than increase it.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.