Closed Bug 1653670 Opened 4 years ago Closed 4 years ago

Website gives SSL_ERROR_NO_CYPHER_OVERLAP when in private mode

Categories

(Firefox :: Private Browsing, defect, P2)

defect

Tracking

()

RESOLVED WORKSFORME

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Private Browsing

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.

The severity field is not set for this bug.
:baku, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(amarchesini)
Flags: needinfo?(amarchesini)
Priority: -- → P2

The severity field is not set for this bug.
:baku, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(amarchesini)

I would keep the same security field value of bug 1642592.

Severity: -- → S4
Flags: needinfo?(amarchesini)
Depends on: 1642592

(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!

Flags: needinfo?(michaell)

New server with the same SSL configuration is setup at https://mozilla-ssl-test.rainn.org/.

Flags: needinfo?(michaell)

Further testing shows that bug may not exist on IOS versions of firefox.

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?

Flags: needinfo?(kjacobs.bugzilla)

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?

Flags: needinfo?(kjacobs.bugzilla) → needinfo?(michaell)

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?

Flags: needinfo?(michaell)

Thanks. If the server is using JDK for SSL, this is most likely https://bugs.openjdk.java.net/browse/JDK-8210334.

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.

Glad to hear this is resolved. Thanks again for the report!

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.