Closed Bug 1284840 Opened 5 years ago Closed 5 years ago fails to load on Nightly builds since 2016-06-29


(Core :: Security: PSM, defect, P1)




Tracking Status
firefox50 --- fixed


(Reporter: jaws, Unassigned)



(Whiteboard: [psm-backlog])


(1 file)

Secure Connection Failed

An error occurred during a connection to 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?
Flags: needinfo?(dkeeler)
Flags: needinfo?(VYV03354)
Works for me.
Flags: needinfo?(VYV03354)
According to 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
Flags: needinfo?(dkeeler) → needinfo?(jaws)
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.
Flags: needinfo?(jaws)
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.)
Component: Other → Security: PSM
Priority: -- → P1
Product: Websites → Core
Whiteboard: [psm-backlog]
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.

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).
Attachment #8768763 - Flags: review?(dkeeler) → review+
Comment on attachment 8768763 [details]
Bug 1284840 - Don't forget TLS intolerance when a DHE-based cipher is used.

Review request updated; see interdiff:
Pushed by
Don't forget TLS intolerance when a DHE-based cipher is used. r=keeler
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.