Open Bug 1899605 Opened 2 months ago Updated 1 month ago

improve error page messaging when a server closes a TLS connection after the handshake has started

Categories

(Core :: Networking, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: mozilla.bugs.grokchem, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20161205004004

Steps to reproduce:

Proxy over Tor to this page:

https://karma.im5wixghmfmt7gf7wb4xrgdm6byx2gj26zn47da6nwo7xvybgxnqryid.onion/api/is/cloudflare/html/

Respond to the warning by clicking for advanced options and accept the risks.

Actual results:

“Secure Connection Failed

An error occurred during a connection to karma.im5wixghmfmt7gf7wb4xrgdm6byx2gj26zn47da6nwo7xvybgxnqryid.onion.

  • 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.

Expected results:

The site should load regardless of the verifiability of the certificate. The user accepted the risks which means ultimately the browser needs to exit nanny mode. It is also an onion site which has an extra layer of security Firefox is neglecting.

I could not reopen bug 1322174 so I created a clone of it.

Version is 115.10.0esr (64-bit)

OS: Unspecified → Linux
Hardware: Unspecified → ARM64

The Bugbug bot thinks this bug should belong to the 'Firefox::Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Security

Ed, I am not able to reproduce the issue on Win11 and Ubuntu 22.04 using FF build 115.10.0esr(20240408145128). Link mention does not to open neither in Chrome, is there a typo in it? Also the build id mention by you is really old, can you please update and provide a functional link? Thank you.

Flags: needinfo?(mozilla.bugs.grokchem)

Regarding the inaccessibility of websites in the onion domain, you should better contact the developers of the TOR Browser.

HTTP log of reproducing this behavior (first the self-signed cert is displayed, when accepting the other cert error is displayed).

I think this fits better into PMS. Please bounce back or redirect to other component if this is not correct.

Component: Security → Security: PSM
Flags: needinfo?(mozilla.bugs.grokchem)
Product: Firefox → Core
Version: other → unspecified

If I'm reading that log correctly, the server (or something along the path) is interrupting the connection. Does this work in other browsers? Does connecting to that server work without tor?

Flags: needinfo?(mozilla.bugs.grokchem)

Link mention does not to open neither in Chrome, is there a typo in it?

No typo. Chromium fails with NET::ERR_CERT_AUTHORITY_INVALID and offers an advanced override just as FF does. Then it prints “This site can’t be reached”, which is probably accurate. I think Chromium does the right thing here.

Note to reproduce this, you need Firefox set to proxy over Tor.

Also the build id mention by you is really old, can you please update and provide a functional link? Thank you.

Luckily it looks like someone was able to reproduce it and post a log. My version may be old but it’s likely the newest Debian version.

Regarding the inaccessibility of websites in the onion domain, you should better contact the developers of the TOR Browser.

This is not a Tor problem. Tor Browser is based on Firefox and it comes from upstream. TB devs would rightfully direct me to Mozilla.

FWIW, TB gives a different initial warning (Error code: SSL_ERROR_BAD_CERT_DOMAIN), which differs from a self-signed cert warning, but it still lands on the same erroneous error msg: Secure Connection Failed. Mozilla FF also ends that way.

If I'm reading that log correctly, the server (or something along the path) is interrupting the connection.

I heard that this server is often overloaded and that this error is a consequence of the server struggling. Lately, I rarely get service. Nonetheless, it seems like a defect no matter what because the user waives off the “Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT” and then still gets pestered with “Secure Connection Failed”. Perhaps the connection failure is unrelated to security, but the error message implies otherwise. So the error message is misleading.

Does this work in other browsers?

The website fails to function in all browsers in all my tests. But Chromium gives a correct error message: “This site can’t be reached”. FF-based browsers give an error message that misleads users into thinking their express instruction to ignore security is being ignored, so the user thinks they are being nannied. When really it’s just an incorrect error message.

Does connecting to that server work without tor?

At the risk of muddying the waters, I will say that the clearnet URL is

https://karma.crimeflare.eu.org/api/is/cloudflare/html/

That clearnet service is strictly clearnet and tor users who go there will get refused, I believe. I never use it, but I would speculate that the clearnet server is also using a self-signed cert and you can probably reproduce the anomaly there too.

Flags: needinfo?(mozilla.bugs.grokchem)

Just to clarify, I said my expectation in the OP was that the site should load. That was before I heard that the website has severe availability issues. I suspected it, but nonetheless I knew the error message must be wrong since it implies a security issue.

(In reply to ed from comment #7)

Chromium fails with NET::ERR_CERT_AUTHORITY_INVALID and offers an advanced override just as FF does. Then it prints “This site can’t be reached”, which is probably accurate. I think Chromium does the right thing here.

That's essentially what Firefox is saying. This is just a messaging issue.

Status: UNCONFIRMED → NEW
Type: defect → enhancement
Component: Security: PSM → Security
Ever confirmed: true
OS: Linux → All
Product: Core → Firefox
Hardware: ARM64 → All
Summary: The page you are trying to view cannot be shown because the authenticity of the received data could not be verified → improve error page messaging when a server closes a TLS connection after the handshake has started
Severity: -- → S4
Priority: -- → P3

This could either block better-cert-errors or necko-error. Opting for necko-error, due to this page being about:neterror and not about:certerror. I'd like to move Networking, due to a network event (connection being closed) causing the error and the neterror being in their domain knowledge. Feel free to move back if my assessment is wrong.

Blocks: necko-error
Component: Security → Networking
Product: Firefox → Core
Whiteboard: [necko-triaged][necko-priority-new]
Severity: S4 → N/A
Whiteboard: [necko-triaged][necko-priority-new] → [necko-triaged]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: