User Agent: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140605174243 Steps to reproduce: I have updated new Firefox 31 and since then I cannot access our subversion server. Our subversion server has only SSLv3 enabled and all TLS versions disabled, because of some problem with windows cygwin svn client: SSLProtocol All -TLSv1.1 -TLSv1.2 -TLSv1 Actual results: Accessing that server results to error Secure Connection Failed An error occurred during a connection to svn.abacus.ch. SSL peer selected a cipher suite disallowed for the selected protocol version. (Error code: ssl_error_cipher_disallowed_for_version) In Firefox 30 there was an error ssl_error_illegal_parameter_alert on ctrl-f5 - see my comment in bug 968449. Current setting in Firefox 31 is: security.tls.version.max = 3 security.tls.version.min = 0 If I set security.tls.version.max to "0", the connection works without error. Currently, it is not possible to connect to sslv3-only servers without setting security.tls.version.max to "0", but then every connection will be sslv3-only even if any other server supports better encryption. Expected results: Firefox does use two options security.tls.version.max and security.tls.version.min, which should define the best and the worst encryption. Firefox should try the best encryption, but if server does not support that encryption, Firefox should try worse encryption untill it reach the worst configured encryption. Setting security.tls.version.max same as "min" to value "0" (sslv3 only) makes connection work. If the Apache server supports sslv3 and tlsv1 and tlsv1.1+ are disabled SSLProtocol All -TLSv1.1 -TLSv1.2 Firefox 31 reports no error and can connect (Firefox 30 works fine too, there is no problem as described in 968449. I have found the description of fallback to worse version on http://kb.mozillazine.org/Security.tls.version "There is currently no fallback from TLS 1.1/1.2 to earlier protocols. Thus, selecting security.tls.version.max = 2 (or 3) for TLS 1.1 (or 1.2) support results in the connection failing when the server connected to doesn't support that version. Once the fallback is implemented, the default for security.tls.version.max will be changed to 3 to utilize the most recent TLS 1.2 version by default. " Problem is, that fallback from tlsv1 to sslv3 does neither works. Setting security.tls.version.max to "1" does neither help and firefox shows error. For sslv3-only server must be set "0" for version.max. I have done tcpdump for chrome and chrome opens three connections to the server and does use different encryptions for every connection. The connections with failed encryption are close and chrome will use only the connection with best accepted encryption.

Brian, can you clarify what's wrong / what needs to happen here?

Richard, please find somebody to look at this.

I can confirm this behavior in FF31 on Ubuntu 12.04. I had a customer with an internal Apache server configured with an outdated SSLProtocol setting allowing only SSLv3. I was able to work around the problem by downgrading security.tls.version.max to 0, but 1 and 2 did not work. Disabling security.ssl3.ecdhe_rsa_aes_256_sha also worked. I resolved the problem by fixing the server so it uses SSLv3, TLSv1, 1.1 and 1.2.

Correction, the customer changed SSLProtocol to `-ALL +TLSv1.2 +SSLv3`. They also tried `-ALL +TLSv1.2 +TLSv1.1 +SSLv3`, but it failed with the same error.

Hello, Problem is, that Firefox opens one connection and try the best version (security.tls.version.max). If this fails, because server is not configured or completely does not support it, Firefox shows error message. Firefox should probably try to open new connection to server with lower encryption (security.tls.version - 1) and try it again, and so on until the security.tls.version is less then security.tls.version.min and then write an error. As I have written, Chrome opens parallel more connections and choose probably the connection with the best encryption and closes the others. Regards, Robert Wolf.

Hello: I'll add my two cents here. I agree with Robert Wolf: it seems like it's desirable to have FF start at the best version and work it's way down to less secure options rather than just croaking after one try. Thanks, Greg

Trying to parse the above comments, it's unclear to me whether this is a Firefox bug or a misconfiguration in the server, or both. Is there a test URL that we can load to see what's actually happening? I suspect that the problem is actually this: > security.ssl3.ecdhe_rsa_aes_256_sha There are a bunch of ciphersuites enabled with preferences like that which will result in SSL_ERROR_CIPHER_DISALLOWED_FOR_VERSION if they are ever actually negotiated. Compare these two lists: http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#628 http://dxr.mozilla.org/mozilla-central/source/netwerk/base/public/security-prefs.js#20

Locally I called it a bug for both server and client. The server was configured with an outdated, insecure setting (SSLv3 only), but I don't think it's unreasonable to expect browsers to work with that poor setting. Really, I wouldn't mind the complete deprecation of SSLv3, but until that day comes I think this is a regression. I don't have a server to test this on, but here are the approximate steps to reproduce: 1. Install: - Apache httpd 2.2.23 or later - OpenSSL 1.0.1h - mod_ssl 2. Configure httpd for HTTPS with these settings: - `SSLProtocol -ALL +SSLv3` - `SSLCipherSuite HIGH:!aNULL:!3DES` 3. Connect to the server with FF31 (on Linux?)

I'm open to pointing devs to my website, but I would rather not reveal the details in a public forum. My ISP hasn't figured out what they're going to do yet, as far as I can tell, so I think it'll probably reproduce the problem at least for awhile. I'll respond to an email from rbl unless there's another way to do it. Thanks, Greg

Oops, sorry, should have been clearer. I'll respond via email to Richard Barnes. Thanks! Greg

(In reply to Richard Barnes [:rbarnes] from comment #7) > Trying to parse the above comments, it's unclear to me whether this is a > Firefox bug or a misconfiguration in the server, or both. Is there a test > URL that we can load to see what's actually happening? > > I suspect that the problem is actually this: > > > security.ssl3.ecdhe_rsa_aes_256_sha > > There are a bunch of ciphersuites enabled with preferences like that which > will result in SSL_ERROR_CIPHER_DISALLOWED_FOR_VERSION if they are ever > actually negotiated. Compare these two lists: > > http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con. > c#628 > http://dxr.mozilla.org/mozilla-central/source/netwerk/base/public/security- > prefs.js#20 Hello, you are right. If I disable all security.ssl3.ecdhe_rsa ciphers, I can connect to server without any problem, even with security.tls.version.max set to 3. It's not server bug - apache works fine, it's maybe server config bug (the configuration is correct but unsecure). And it's not firefox bug - it's feature. Maybe Firefox should call ssl3_CipherSuiteAllowedForVersionRange with vrange containing (SSLVersionRange.min , SSLVersionRange.max), then try range (SSLVersionRange.min, SSLVersionRange.max-1), then (SSLVersionRange.min, SSLVersionRange.max-2) etc. until SSLVersionRange.min == SSLVersionRange.max-i. But I am not programmer and I don't know, how the ssl3_CipherSuiteAllowedForVersionRange() is used exactly. Or Firefox could display warning, that FF is unable to use strong cipher for this connection (SSLv3) but it can use weak cipher and display some button to continue. Same as done with untrusted certificate. Would this be easy and possible solution? Regards, Robert Wolf.

I have not confirmed this, but it seems that this bug also affects firefox-24.7.0 , per https://bugs.gentoo.org/show_bug.cgi?id=519070

Hola: Again, I agree with Herr Wolf. Any of the suggestions he's come up with so far get thumbs-ups from me. Thanks, Greg

static SECStatus ssl3_HandleServerHello(sslSocket *ss, SSL3Opaque *b, PRUint32 length) { [...] /* config_match already checks whether the cipher suite is * acceptable for the version, but the check is repeated here * in order to give a more precise error code. */ if (!ssl3_CipherSuiteAllowedForVersionRange(temp, &vrange)) { desc = handshake_failure; errCode = SSL_ERROR_CIPHER_DISALLOWED_FOR_VERSION; goto alert_loser; } [...] } Here's probably what's happening: 1. Firefox offers a bunch of cipher suites, some of which are not allowed for SSL 3.0. 2. The server only has SSL 3.0 enabled, but the server picks a cipher suite that isn't allowed for SSL 3.0. 3. Firefox (NSS) receives the server's cipher suite selection and notices that the server chose a cipher suite that is not valid for SSL 3.0, and returns the SSL_ERROR_CIPHER_DISALLOWED_FOR_VERSION error. Note that if you search the source code for NSS, SSL_ERROR_CIPHER_DISALLOWED_FOR_VERSION can only be returned when the server chooses a cipher suite that isn't allowed for the given version. Consequently, this is a bug in the server. Now, until recently, Mozilla would probably work around the server bug this problem by adding SSL_ERROR_CIPHER_DISALLOWED_FOR_VERSION to list of errors that would trigger the non-secure version fallback logic. Doing so would make the broken sites work. Historically, Google Chrome, MSIE, and other browsers have been much more liberal about doing the non-secure fallback than Firefox has been. (Basically, they use a blacklist of error codes, but Firefox uses a whitelist of error codes.) Consequently, they already do this non-secure fallback for this error. That's why they work and Firefox doesn't. However, Firefox will disable SSL 3.0 by default and more-or-less stop supporting SSL 3.0 in Firefox 34 and maybe Firefox 31 ESR. Consequently, I doubt Mozilla will do anything to work around these broken servers. Further, even if the user re-enabled SSL 3.0, which won't be recommended, the non-secure fallback logic has been changed so that it won't fall back to SSL 3.0. And, if you change both of those settings then you'll be using a non-secure and (probably) totally unsupported configuration. Consequently, the solution is to fix the server to enable TLS 1.2 (or, at least TLS 1.). Mozilla offers a guide for TLS configuration here: https://wiki.mozilla.org/Security/Server_Side_TLS. I understand that the initial bug reporter specifically disabled TLS 1.0+ because of a compatibility issue with another client. I suggest finding a different way to resolve that issue. Please see http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html and other pages about why SSL 3.0 is considered to be non-secure now. I recommend either RESOLVED INVALID or moving this to Tech Evangelism.

Also, I recommend that everybody reset security.tls.version.max and security.tls.version.min to their default values.

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #14) > Further, even if the user re-enabled SSL 3.0, which won't be recommended, the > non-secure fallback logic has been changed so that it won't fall back to SSL > 3.0. The non-secure fallback is unnecessary in this case. If the user enabled SSL 3.0, the server will negotiate SSL 3.0 "securely" except that SSL 3.0 is insecure in itself. The problem is, the server doesn't exclude EC cipher suites even if the server chose SSL 3.0. So, if the server administrators disable TLS 1.0+ on purpose, they should also disable EC cipher suites to avoid the server bug. Those ciphers will be unusable anyway. Of course it's much better to enable TLS 1.0+.

Resolving this as INVALID, which means "works as intended". After bug 1076983, SSL 3.0 is no longer supported. Thanks to everybody that reported information about these issues!