secure connection failed on a site which states connection is secure

RESOLVED FIXED in Firefox 64

Status

()

defect
P1
normal
RESOLVED FIXED
2 years ago
9 months ago

People

(Reporter: mertschf, Assigned: keeler)

Tracking

56 Branch
mozilla64
Points:
---

Firefox Tracking Flags

(firefox64 fixed)

Details

(Whiteboard: [psm-assigned])

Attachments

(3 attachments)

Posted image screenshot.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170810180547

Steps to reproduce:

Trying to go to https://msdn.microsoft.com/en-us/library/vstudio/microsoft.visualstudio.testtools.unittesting.classcleanupattribute.aspx


Actual results:

Got a "secure connection failed" dialog with a green padlock


Expected results:

Enter the site successfully or have a broken padlock
the same issue happen son chrome and safari
looks like it's server side issue that the connection closes unexpectedly, or something similar
(In reply to Tooru Fujisawa [:arai] from comment #2)
> the same issue happen son chrome and safari
*happens on
Not a browser issue. Please contact Microsoft.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
(In reply to Kohei Yoshino [:kohei] from comment #4)
> Not a browser issue. Please contact Microsoft.

Yes, it seems to be a server issue, but the browser display a nonsensical UI, how is this not a browser issue?
Now I understand what you mean.
Status: RESOLVED → REOPENED
Component: Untriaged → Site Identity and Permission Panels
Ever confirmed: true
Resolution: INVALID → ---
Huh, indeed. This doesn't look like a frontend issue to me (we're correctly displaying the information from nsIWebProgressListener, afaict), so I'll move it into the more general Security component.
Status: REOPENED → NEW
Component: Site Identity and Permission Panels → Security
Component: Security → Security: PSM
Product: Firefox → Core
Well, the site seems to work now, but there's clearly a way to enter this inconsistent state. I guess it's good to have an open bug on the issue. Maybe we'll figure out the cause someday.
Priority: -- → P5
Whiteboard: [psm-backlog]
I've the same issue on my server. The padlock is green, connection marked as secure, but Firefox displays "Secure connection failed" without error codes or any additional info and even without suggestion to add security exception.

I'm using Firefox Quantum 62.0.3 (64-bit) on Arch Linux. The CA certificate is installed to the System Trust (/etc/ca-certificates/trust-source/anchors) folder. Other applications work fine with this ca-certificate: Mutt, Сhromium, GNOME Web etc.

My ca-certificate for testing:

-----BEGIN CERTIFICATE-----
MIICwDCCAkigAwIBAgIUXiv0Yxf5/ClYo2b1iBlUnR5X6IkwCgYIKoZIzj0EAwIw
gZcxCzAJBgNVBAYTAlJVMR0wGwYDVQQIDBRzdmVyZGxvdnNrYWphLW9ibGFzdDEW
MBQGA1UEBwwNeWVrYXRlcmluYnVyZzEKMAgGA1UECgwBazELMAkGA1UECwwCY2Ex
FjAUBgNVBAMMDWsuaW1tLnVyYW4ucnUxIDAeBgkqhkiG9w0BCQEWEW1vYkBrLmlt
bS51cmFuLnJ1MB4XDTE4MTAwOTExMTY1MloXDTIwMDMwNDExMTY1MlowgZcxCzAJ
BgNVBAYTAlJVMR0wGwYDVQQIDBRzdmVyZGxvdnNrYWphLW9ibGFzdDEWMBQGA1UE
BwwNeWVrYXRlcmluYnVyZzEKMAgGA1UECgwBazELMAkGA1UECwwCY2ExFjAUBgNV
BAMMDWsuaW1tLnVyYW4ucnUxIDAeBgkqhkiG9w0BCQEWEW1vYkBrLmltbS51cmFu
LnJ1MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEeeLj5FV+NfgwI8jQVrL1iQqGcOEr
d/3yyg+ruddJ4Usswqb9YYkp9N0H338Trr8mv9iqv85rbn7naoATWuQI21/vjt6j
ehvytDJ6A1vUi1M1aS7sxRRhix9r/mqEeqhXo1MwUTAdBgNVHQ4EFgQUAYJMb2Vj
qZhZqhX319B1GbhPTUMwHwYDVR0jBBgwFoAUAYJMb2VjqZhZqhX319B1GbhPTUMw
DwYDVR0TAQH/BAUwAwEB/zAKBggqhkjOPQQDAgNmADBjAi8xZMWExYRNLJyk/cmY
GJAPKXJ1KLgjMdo7MK+gqFfFyz3qzUy6YSmvzC+wP3h5DwIwF/E8oNMe63gBttdg
Tn9/CDE2X8u/5s0c1hAop0D5Oj1LNw111G/16qd55EFefU4T
-----END CERTIFICATE-----

Server is located at

https://k.imm.uran.ru

Оn successful connection it should display "404 - Not found" page.
Thanks - I think I figured it out. If the TLS handshake completes but then the connection is closed unexpectedly, the docshell will call nsSecureBrowserUIImpl::OnLocationChange with aFlags set to LOCATION_CHANGE_ERROR_PAGE. nsSecureBrowserUIImpl completely ignores this, extracts the security information from the channel (remember - the handshake completed successfully, so we have a certificate), and calls OnSecurityChange with STATE_IS_SECURE. Probably all we need to do is check for that flag and set the state to STATE_IS_INSECURE if it's set. Note that this isn't a regression as of bug 832834 - this flaw was present in the original implementation.
Assignee: nobody → dkeeler
Priority: P5 → P1
Whiteboard: [psm-backlog] → [psm-assigned]
Before this patch, if a TLS handshake completed but the server then closed the
connection without reading or writing, Firefox would display a connection reset
error page with a secure lock icon. This is misleading and confusing, so in this
patch, nsSecureBrowserUIImpl::OnLocationChange checks if an error page is being
loaded and sets the state to not secure.
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/29ecf05f6a7b
error pages are always not secure r=Gijs
https://hg.mozilla.org/mozilla-central/rev/29ecf05f6a7b
Status: NEW → RESOLVED
Closed: 2 years ago9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in before you can comment on or make changes to this bug.