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.
Component: Untriaged → Networking: FTP
Product: Firefox → Core
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).
Component: Networking: FTP → Security: PSM
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).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
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.
Resolution: WONTFIX → INVALID
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.
You need to log in before you can comment on or make changes to this bug.