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
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 email@example.com: https://hg.mozilla.org/integration/autoland/rev/29ecf05f6a7b error pages are always not secure r=Gijs
You need to log in before you can comment on or make changes to this bug.