Closed Bug 1642592 Opened 4 years ago Closed 4 years ago

TLS site does not work in private window

Categories

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

76 Branch
defect

Tracking

()

VERIFIED FIXED
81 Branch
Tracking Status
firefox81 --- verified

People

(Reporter: david.balazic, Assigned: keeler)

References

Details

(Whiteboard: [psm-assigned])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

When opening the same website in regular window it works, but when opening in private window, it gives an error:

Secure Connection Failed

An error occurred during a connection to foo.bar.baz:8443. Cannot communicate securely with peer: no common encryption algorithm(s).

Error code: SSL_ERROR_NO_CYPHER_OVERLAP

...

It looks like your network security settings might be causing this. Do you want the default settings to be restored?
"Restore default settings"

the website domain (foo.bar.baz) is in the security.tls.insecure_fallback_hosts setting.
also, I have security.tls.version.enable-deprecated set to TRUE

The website is not public.

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

Component: Untriaged → Security: PSM
Product: Firefox → Core

Today's nightly behaves the same.

More details:

  • start firefox-nightly

  • open https://foo.bar.baz:8443/x

  • it requires a client certificate, select one, then continue
    Result: page works

  • open a private window

  • open https://foo.bar.baz:8443/x

  • it requires a client certificate, select one, then continue
    Result: page works

  • close all private windows

  • open a private window

  • open https://foo.bar.baz:8443/x
    Result: page does not work, the display says:

Secure Connection Failed

An error occurred during a connection to foo.bar.baz:8443. Cannot communicate securely with peer: no common encryption algorithm(s).

Error code: SSL_ERROR_NO_CYPHER_OVERLAP

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

Learn more…

It looks like your network security settings might be causing this. Do you want the default settings to be restored?


again, i have this non-standard settings (otherwise the site never works):
the website domain (foo.bar.baz) is in the security.tls.insecure_fallback_hosts setting
security.tls.version.enable-deprecated set to TRUE

SSL_ERROR_NO_CYPHER_OVERLAP is an error the server sends to the client to indicate that it thinks there aren't any ciphersuites that both it and the client have enabled. Clearly that's not the case since you can connect in non-private browsing. My first guess is this is a server bug. Given that you have to use an old version of TLS and insecure TLS fallback to access this server, I'm assuming it's quite old. Is there an updated version of the server you can install?

Flags: needinfo?(david.balazic)

The server is: WebLogic Server Version: 10.3.3.0

Updating the server is currently not an option.

Flags: needinfo?(david.balazic)

According to this https://en.wikipedia.org/wiki/Oracle_WebLogic_Server that version is from 10 years ago.
If you can't update the server, does Firefox work if you set security.tls.version.max to 1? Did Firefox ever work with this site?

Flags: needinfo?(david.balazic)

Did Firefox ever work with this site?

It works even with the latest. Just not in private mode.
I tested Firefox 56 and it behaves as described in comment #0

does Firefox work if you set security.tls.version.max to 1?

Yes, with this setting, the website works in private mode (and regular too).
I tested this with the todays nightly build.

Flags: needinfo?(david.balazic)

To clear up: the following settings make the website work in both regular and private more in nightly version 79.0a1 (2020-06-10) (64-bit)

security.tls.version.enable-deprecated true
security.tls.version.max 1

This of course this makes me get a "bad" score on https://www.howsmyssl.com/

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(dkeeler)
Severity: -- → S4
Flags: needinfo?(dkeeler)

Can this be installed in parallel to the regular release and nightly? Without any effect on them?

That's my understanding - they should use separate installation directories and profiles.

Oh - I misread. This should behave like Nightly, so it will replace your current Nightly installation and use your current Nightly profile.

79.0a1 (2020-06-26) (64-bit)

tested, it behaves the same as in comment #3

Flags: needinfo?(david.balazic)

I suspect this is due to https://bugs.openjdk.java.net/browse/JDK-8210334 (see bug 1653670).

What JDK version is the WebLogic Server using?

Flags: needinfo?(david.balazic)

it is using Sun Java SE 1.6.0_18

Flags: needinfo?(david.balazic)

note to myself: the actual server address is https://a-people:8443/WS.web

If you set security.tls.version.max to 3 (TLS 1.2), does the site work in private browsing mode?

No: Error code: SSL_ERROR_NO_CYPHER_OVERLAP

Note:
as described in comment 3 : it works first time, then I close (all) private window, open a private windows again and try to load that website, then it gives the error

This one works.

The page opens in private window, even after closing and reopening the private window.

Flags: needinfo?(david.balazic)
Assignee: nobody → dkeeler
Priority: -- → P1
Whiteboard: [psm-assigned]

When the last private browsing context exits, observers are notified of the
event "last-pb-context-exited". Before this patch, the private browsing shared
TLS state object would clear its list of insecure fallback sites opon observing
this. However, this is not correct, because the list should be set to reflect
the current set of insecure fallback sites as parsed from the preference
"security.tls.insecure_fallback_hosts" (which is by default empty, but wouldn't
be if a user has modified it).

Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/73d8b0959b4d
properly reinitialize insecure fallback hosts when clearing private data r=rmf
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Flags: qe-verify+

Hi David,

Could you please verify if this issue is fixed? https://archive.mozilla.org/pub/firefox/candidates/81.0b9-candidates/build1/

I’ve tried to verify it but it seems that the test page isn’t public.

Flags: needinfo?(david.balazic)

Can that be installed in parallel to the regular version?

I tried this ZIP and the problem does not happen with it.

It also seems to be fixed in regular version 80.0.1 (64-bit). (release, not beta)

It seems this bug can be closed!

Flags: needinfo?(david.balazic)

Thank you David.

Based on the above comment, marking this as verified fixed.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: