Website gives SSL_ERROR_NO_CYPHER_OVERLAP when in private mode
Categories
(Firefox :: Private Browsing, defect, P2)
Tracking
()
People
(Reporter: michaell, Unassigned)
References
()
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36
Steps to reproduce:
Step 1) Open firefox in a normal, non private window.
Step 2) Navigate to https://online.rainn.org/tos/0
Step 3) Observe that website works.
Step 4) Hit CTRL-SHIFT-P to open up a firefox private window.
Step 5) In the new private window, navigate to https://online.rainn.org/tos/0
Step 6) Observe that the website does NOT work.
Actual results:
Website works in normal browsing, and fails with SSL_ERROR_NO_CYPHER_OVERLAP in private mode.
Expected results:
Either both should succeed, or both should fail.
The ability to handshake to a website should not change depending on whether or not private mode is used.
Tested on multiple devices and OSes.
Still a problem as of nightly 20200717093907
Possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=1642592
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Hello,
A server-side workaround was discovered by removing TLS 1.3 from the server.
If needed, I can give out a link to another server with the same issue.
Comment 4•4 years ago
|
||
The severity field is not set for this bug.
:baku, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
The severity field is not set for this bug.
:baku, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 6•4 years ago
|
||
I would keep the same security field value of bug 1642592.
Comment 7•4 years ago
|
||
(In reply to michaell from comment #3)
Hello,
A server-side workaround was discovered by removing TLS 1.3 from the server.
If needed, I can give out a link to another server with the same issue.
That would be helpful - thanks!
New server with the same SSL configuration is setup at https://mozilla-ssl-test.rainn.org/.
Further testing shows that bug may not exist on IOS versions of firefox.
Comment 10•4 years ago
|
||
Thanks!
Looking at the packets of the handshakes, the server is closing the connection after receiving the client hello in the private browsing case, so this is probably due to differences in the handshakes. The only substantive differences I can see are that the private browsing handshake doesn't include a session_ticket extension or a psk_key_exchange_modes extension. I don't think the former is mandatory, and my understanding is the latter is only mandatory if there's also a pre_shared_key extension, but there isn't, so I'm wondering if this is a bug in the server.
Kevin - thoughts?
Comment 11•4 years ago
•
|
||
This is reproducible in non-private browsing by setting security.ssl.disable_session_identifiers
to true. The cause is a lack of psk_key_exchange_modes
in a Client Hello that advertises TLS 1.3. Since RFC 8446 only requires psk_key_exchange_modes
if pre_shared_key
is also advertised (which it isn't), this does look like a server bug.
On our end, ssl3_HandleAlert
translates the handshake_failure alert into a SSL_ERROR_NO_CYPHER_OVERLAP code, which in this case is incorrect.
@michaell, is there any setting enabled on the server that would require resumption to be supported by the client?
Reporter | ||
Comment 12•4 years ago
|
||
Hello,
I will investigate the settings. This may take a while as I'm not too familiar with this sort of thing.
However, I did stumble across https://bugs.openjdk.java.net/browse/JDK-8213202 Could that be relevant?
Comment 13•4 years ago
|
||
Thanks. If the server is using JDK for SSL, this is most likely https://bugs.openjdk.java.net/browse/JDK-8210334.
Reporter | ||
Comment 14•4 years ago
|
||
Hello,
I was unable to find any specific settings relevant to this within the server.
However:
Updating the JDK to 11.0.8 has resolved this issue.
I no longer believe this is a mozilla related issue. I am not confident in this diagnosis, and thus will not self-close the report.
If I am correct in this not being a Mozilla related issue, feel free to close this report.
Comment 15•4 years ago
|
||
Glad to hear this is resolved. Thanks again for the report!
Description
•