|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
58 bytes, text/x-review-board-request
|Details | Review|
Secure Connection Failed An error occurred during a connection to assets.mozilla.org. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP Keeler / Masatoshi, could this be related to bug 1279479?
Works for me.
According to https://www.ssllabs.com/ssltest/analyze.html?d=assets.mozilla.org these are the cipher suites that are supported by that site: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 1024 bits FS WEAK 128 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 1024 bits FS WEAK 256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 1024 bits FS WEAK 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits FS WEAK 128 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 1024 bits FS WEAK 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits FS WEAK 256 Which means that as of bug 1279479 we're failing the first handshake and then attempting to fall back with some DHE cipher suites enabled. Like :emk, the fallback mechanism seems to work for me on that site, which is why I'm surprised it doesn't work for :jaws. I'm curious - are you seeing the "reset security prefs" button as added in bug 1252068? Resetting your cipher suite prefs might help ("security.ssl3.*"). In any case, that server needs to have its configuration updated as per https://wiki.mozilla.org/Security/Server_Side_TLS
It's touchy for me. The page may load but some of the JS resources may get blocked. Or I refresh it and then see the SSL error. I just got an SSL_ERROR_ILLEGAL_PARAMETER_ALERT error. I don't see a "reset security prefs" button on the SSL error page. In about:config the only pref changed under security.ssl* is security.ssl.errorReporting.automatic=true.
Ah - I'm seeing what you're seeing now. New host parallelism (bug 865314) may be interacting poorly with weak cipher suite fallback detection. What could be happening is a number of parallel connections are initially made. The first one to fail triggers the weak cipher suite fallback. However, since the others are still in flight, when they fail, the fallback code essentially says, "well, that didn't work - better terminate these connections and reset our fallback information. (At least, I think that's what's going on - I'll have to investigate further.)
HandshakeCallback does not treat DHE-based cipher suites as weak. https://dxr.mozilla.org/mozilla-central/rev/95ffbc4ff63584631c408e8d9912961fcf68bb09/security/manager/ssl/nsNSSCallbacks.cpp#1127 So it will call removeInsecureFallbackSite https://dxr.mozilla.org/mozilla-central/rev/95ffbc4ff63584631c408e8d9912961fcf68bb09/security/manager/ssl/nsNSSCallbacks.cpp#1222 that calls forgetIntolerance. https://dxr.mozilla.org/mozilla-central/rev/95ffbc4ff63584631c408e8d9912961fcf68bb09/security/manager/ssl/nsNSSIOLayer.cpp#1772 Probably this is the reason of SSL_ERROR_ILLEGAL_PARAMETER_ALERT on reload.
Created attachment 8768763 [details] Bug 1284840 - Don't forget TLS intolerance when a DHE-based cipher is used. Review commit: https://reviewboard.mozilla.org/r/62826/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/62826/
I also removed UI degradation for fallback cipher suites.
Comment on attachment 8768763 [details] Bug 1284840 - Don't forget TLS intolerance when a DHE-based cipher is used. https://reviewboard.mozilla.org/r/62826/#review60058 Ah, I see. LGTM. Please also add testcases in test_fallback_cipher.js that will exercise this bug (I think adding an extra 'yield startClient(...)' in each successful fallback case should do it).
Comment on attachment 8768763 [details] Bug 1284840 - Don't forget TLS intolerance when a DHE-based cipher is used. Review request updated; see interdiff: https://reviewboard.mozilla.org/r/62826/diff/1-2/
Pushed by VYV03354@nifty.ne.jp: https://hg.mozilla.org/integration/autoland/rev/e3dcf062007e Don't forget TLS intolerance when a DHE-based cipher is used. r=keeler