TLS site does not work in private window
Categories
(Core :: Security: PSM, defect, P1)
Tracking
()
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"
Reporter | ||
Comment 1•4 years ago
|
||
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.
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Reporter | ||
Comment 3•4 years ago
|
||
Today's nightly behaves the same.
More details:
-
start firefox-nightly
-
it requires a client certificate, select one, then continue
Result: page works -
open a private window
-
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
Assignee | ||
Comment 4•4 years ago
|
||
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?
Reporter | ||
Comment 5•4 years ago
|
||
The server is: WebLogic Server Version: 10.3.3.0
Updating the server is currently not an option.
Assignee | ||
Comment 6•4 years ago
|
||
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?
Reporter | ||
Comment 7•4 years ago
|
||
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.
Reporter | ||
Comment 8•4 years ago
|
||
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/
Comment 9•4 years ago
|
||
The severity field is not set for this bug.
:keeler, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
How does this build behave? https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Zd4OLYnqSwONx-PBiCx7Vw/runs/0/artifacts/public/build/install/sea/target.installer.exe
Reporter | ||
Comment 11•4 years ago
|
||
Can this be installed in parallel to the regular release and nightly? Without any effect on them?
Assignee | ||
Comment 12•4 years ago
|
||
That's my understanding - they should use separate installation directories and profiles.
Assignee | ||
Comment 13•4 years ago
|
||
Oh - I misread. This should behave like Nightly, so it will replace your current Nightly installation and use your current Nightly profile.
Reporter | ||
Comment 14•4 years ago
|
||
79.0a1 (2020-06-26) (64-bit)
tested, it behaves the same as in comment #3
Comment 15•4 years ago
|
||
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?
Reporter | ||
Comment 17•4 years ago
|
||
note to myself: the actual server address is https://a-people:8443/WS.web
Comment 18•4 years ago
|
||
If you set security.tls.version.max
to 3 (TLS 1.2), does the site work in private browsing mode?
Reporter | ||
Comment 19•4 years ago
|
||
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
Assignee | ||
Comment 20•4 years ago
|
||
Can you give this build a try? https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Iw9LtKEWQga_Bdds_LTrKQ/runs/0/artifacts/public/build/install/sea/target.installer.exe
Reporter | ||
Comment 21•4 years ago
|
||
This one works.
The page opens in private window, even after closing and reopening the private window.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 22•4 years ago
|
||
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).
Comment 23•4 years ago
|
||
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/73d8b0959b4d properly reinitialize insecure fallback hosts when clearing private data r=rmf
Comment 24•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 25•4 years ago
|
||
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.
Reporter | ||
Comment 26•4 years ago
|
||
Can that be installed in parallel to the regular version?
Comment 27•4 years ago
|
||
Yes, you can use the zip version for Windows. https://archive.mozilla.org/pub/firefox/candidates/81.0b9-candidates/build1/win64/en-US/
Reporter | ||
Comment 28•4 years ago
|
||
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!
Comment 29•4 years ago
|
||
Thank you David.
Based on the above comment, marking this as verified fixed.
Description
•