When trying to access this site: www.marketday.com I get the 'Network Error Page' The connection to http://www.marketday.com was interrupted while the page was loading. The site could be temporarily unavailable or too busy. Try again in a few moments. Found a range: 20141031125700 a264cdd47217 good 20141031131459 12ac66e2c016 bad http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a264cdd47217&tochange=12ac66e2c016 Possibly broken by bug 1089104 ?

The patch for bug 1092952 will also fix this.

Bug 1092952 was fixed without any changes in our side.

Transferred from bug 1092952. We need either this patch or evangelism.

Comment on attachment 8517708 [details] [diff] [review] Deal with "cipher mismatch intolerant" servers Review of attachment 8517708 [details] [diff] [review]: ----------------------------------------------------------------- r=me with comments addressed. However, don't land this until we've made an effort to reach out to this site so they can fix their broken server. If we don't have to land this, I would rather not. ::: security/manager/ssl/src/nsNSSIOLayer.cpp @@ +1209,5 @@ > socketInfo->SharedState().IOLayerHelpers() > .forgetIntolerance(socketInfo->GetHostName(), socketInfo->GetPort()); > > return false; > + } else if ((err == SSL_ERROR_NO_CYPHER_OVERLAP || While we're here, we should return this else-after-return into just an if. ::: security/manager/ssl/tests/gtest/TLSIntoleranceTest.cpp @@ +32,5 @@ > ASSERT_EQ(SSL_LIBRARY_VERSION_3_0, range.min); > ASSERT_EQ(SSL_LIBRARY_VERSION_TLS_1_2, range.max); > ASSERT_EQ(StrongCipherStatusUnknown, strongCipherStatus); > > + ASSERT_TRUE(helpers.rememberStrongCiphersFailed(HOST, PORT, 0)); We should actually specify a reason here and ensure that getIntoleranceReason does the right thing. ::: toolkit/components/telemetry/Histograms.json @@ +6407,5 @@ > "description": "TLS/SSL version intolerance was falsely detected, server rejected handshake" > }, > "SSL_WEAK_CIPHERS_FALLBACK": { > "expires_in_version": "never", > + "kind": "enumerated", Hmmm - I wonder if telemetry is going to freak out about this change. Well, we'll see.

Reporter, could you contact www.marketday.com to fix their servers?

(In reply to Masatoshi Kimura [:emk] from comment #5) > Reporter, could you contact www.marketday.com to fix their servers? I can try to email the webmaster, but I'm not really that knowledgeable on Server Ops, or security protocols, so I would be very limited in trying to advise them of the exact problem other than a vague 'I get an error accessing your site with latest dev version of Firefox' and pointing them to this bug. Any suggestions on how to approach the issue with them would be helpful.

Their servers only allow the RC4 encryption algorithm. It's possible that they intentionally limit the algorithm to RC4 to mitigate the POODLE attack because their server still support SSL 3.0, unlike the case of bug 1092952. However, RC4 is no longer considered enough strong to protect the connection. We can no longer exchange data securely by using the SSL 3.0 protocol. The most preferable option is adding more secure encryption algorithms to their server configuration and disables SSL 3.0. If they have to enable SSL 3.0 (e.g. they have significant number of customers using IE6), they could fix their server intolerance to keep the current configuration, although it is strongly discouraged. We will drop support for RC4 completely sooner or later. "Server intolerance" means that the server's behavior does not return the spec compliant response when the client does not offer RC4. Usually they will have to update their server software to fix this. Does this help you?

(In reply to Masatoshi Kimura [:emk] from comment #7) > Their servers only allow the RC4 encryption algorithm. It's possible that > they intentionally limit the algorithm to RC4 to mitigate the POODLE attack > because their server still support SSL 3.0, unlike the case of bug 1092952. > However, RC4 is no longer considered enough strong to protect the > connection. We can no longer exchange data securely by using the SSL 3.0 > protocol. > The most preferable option is adding more secure encryption algorithms to > their server configuration and disables SSL 3.0. If they have to enable SSL > 3.0 (e.g. they have significant number of customers using IE6), they could > fix their server intolerance to keep the current configuration, although it > is strongly discouraged. We will drop support for RC4 completely sooner or > later. > "Server intolerance" means that the server's behavior does not return the > spec compliant response when the client does not offer RC4. Usually they > will have to update their server software to fix this. > > Does this help you? I have CC'd you on the email I sent to MarketDay.

Still after a week have not heard anything from Marketday, not even an acknowledgement of receipt of the the email advising them of the problem. I have nothing further to add, and this bug will likely remain in limbo until other browsers also catch up until the site is not accessible by any modern browser.

I believe the conditions are met to land the patch. (See bug 1092701 and this bug.)

Try link? :)

(In reply to Masatoshi Kimura [:emk] from comment #12) > https://hg.mozilla.org/integration/mozilla-inbound/rev/0bbbb35a7e53 Just tested the m-i build cset: https://hg.mozilla.org/integration/mozilla-inbound/rev/c8839443b511 which also has this patch and I can now access MarketDay.com without problems. thanks for the work-around, still have not heard any words from any of their IT folks, but I'm not entirely confident that the right people even say the email.

Arrrgh, I forgot resolving review comments. I'll land a followup patch.