1230296 - TLS RSA ciphers listed out of order

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[kirill.sinitski]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

As part of compliance testing, initiated a connection to a web server using Firefox 42.0


Actual results:

Observed cipher negotiation, noted TLS_RSA_WITH_AES_128_CBC_SHA was picked over TLS_RSA_WITH_AES_256_CBC_SHA. Confirmed all other browsers operated correctly.


Expected results:

TLS_RSA_WITH_AES_256_CBC_SHA should have been negotiated. You list ciphers out of order, consequently weaker TLS_RSA_WITH_AES_128_CBC_SHA is selected, since it is incorrectly listed first.

In federal space many hardened systems are restricted to a narrow set of ciphers, with TLS_RSA_WITH_AES_256_CBC_SHA defaulted to/expected to be used. Negotiating TLS_RSA_WITH_AES_128_CBC_SHA when TLS_RSA_WITH_AES_256_CBC_SHA is expected will degrade security.

Comment 1

[u408661]

This is not an FTP bug, nothing in the report even references FTP. This belongs under PSM (or perhaps NSS, I'm not sure who's responsible for cipher ordering).

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

My understanding is that AES-256 is not significantly stronger than AES-128 (see https://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html ). Furthermore, the server chooses which ciphersuite to use, so if you want to restrict to ciphersuites with 256-bit symmetric keys, the server shouldn't choose a ciphersuite with 128-bit symmetric keys. Finally, you can disable undesired ciphersuites in Firefox by changing the appropriate about:config pref (for instance, to disable TLS_RSA_WITH_AES_128_CBC_SHA, set the pref "security.ssl3.rsa_aes_128_sha" to false).

Comment 3

[kirill.sinitski]

It doesn't matter what you personally think about cryptographic strength of specific ciphers, existing implementation is not TLS-compliant way to negotiate ciphers. Cipher negotiation works the following way: the first cipher on the list that both server and client report. Considering that TLS_RSA_WITH_AES_128_CBC_SHA is required for RFC compliance with TLS 1.0, Firefox will always INCORRECTLY negotiate TLS_RSA_WITH_AES_128_CBC_SHA over TLS_RSA_WITH_AES_256_CBC_SHA.

Plus, telling the server to fix browser issue is not a good way to fix client-side bug. The server-side fix may end up telling the user to use different, RFC compliant, browser.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

It's not my personal opinion (which is why I linked to a paper about an attack on AES-256 that considerably lowers its practical strength).

RFC 5246 stipulates that the server chooses the cipher suite, but it doesn't specify how (other than that it has to pick something from the client's list if possible). There's nothing that says it must use the first supported cipher suite in common.