1195370 - "Secure Connection Failed" (interrupted/reset) doesn't tell me _why_ it failed

Status: RESOLVED DUPLICATE of bug 1252068

(Core Graveyard :: Security: UI, defect)

Description

[Ron Murray]

Attachment: firefox-error.png

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36

Steps to reproduce:

Tried to go to https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsISpeculativeConnect



Actual results:

Got "Secure Conection Failed" with no explanation as to what exactly was wrong.
"Report This Error" also got a "Try Again".
There doesn't appear to be any indication of what the problem was. I'm behind a Palo Alto firewall which intercepts SSL/TLS connections and provides its own certificate to the browser. Presumably there's something wrong with that certificate, and as a system administrator, I'm in a position to fix the problem (or at least file a bug report with Palo Alto). Unfortunately, I can't do that without knowing exactly what the problem is: the current version of Firefox doesn't provide the usual certificate dialog box with an indication of what was wrong; it just tells me that there's an error. C'mon guys, we're not all idiots, and we deserve a better explanation.
Attached screenshot showing no access to the offending certificate.
Filing this using Chrome, which at least works.


Expected results:

I can accept the failure itself; however, I need to know exactly what's wrong so I can fix it.

Comment 1

[:Cykesiopka]

Hi,

Thanks for the bug report.

This may or may not be a TLS intolerance issue. Could you check what happens when you set the security.tls.version.fallback-limit pref to 2, and if that doesn't work, 1?

Thanks.

Comment 2

[Chapman Flack]

Also experienced in 38.1.1 ESR, Red Hat EL 5 build.

Exact same screen as in original reporter's screenshot, attachment 8648777 [details].

Says "Secure Connection Failed

The connection to the server was reset while the page was loading.

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

Only offers "Try again" and "Report this error" as options, where "Report this error" has only a "Report" button that presumably would provide information to somebody somewhere else, but still there is no information provided to me.

"Please contact the website owners to inform them of this problem" is especially rich, considering I haven't been told anything about the problem myself that I could inform them of. The best I could do would be to waste their time the same way this page wastes mine.

Just like the original reporter, I am the sysadmin. I am the person who needs to get the information this page is hiding.

Is there somebody on the Mozilla team who keeps thinking "gee, most users aren't gearheads and won't care about that information?" and designing the error report UIs accordingly.

Ok fine, but then have a button that says "I am the gearhead. I am the person who needs to care about the details of this failure." And then have it display the details of the failure.

I apologize if my tone seems harsh, but this is not the first time a Firefox update has brought UI changes that put up hostile roadblocks to the people who need to be able to find out what is happening. What does it take for the devs to remember not to do that?

Comment 1 is potentially helpful in one case or another but really misses the point. The bug here is that Firefox detects an error and won't say what it is, even to the people who need to know. The bug isn't fixed by saying "well, maybe the mystery error is X, try Y and see what happens." The bug is fixed by remembering that there has to be a way that people who need to know what the error is can find out.

Incidentally, what are the criteria for changing the status from UNCONFIRMED? Did the original reporter not supply a screenshot? Does the screenshot not show a "Secure Connection Failed" page that utterly lacks any detail about the failure? I could send another screenshot from here, but it's just the same, so it would seem superfluous.

Thanks for listening....

Comment 3

[Ron Murray]

Sorry for the delay with this: we've been moving office.

Firstly, setting security.tls.version.fallback-limit to 2 does indeed solve the immediate problem -- but, as the poster in Comment 2 pointed out, this is not the bug that I reported, which is that the UI currently gives no technical details about the problem. I could understand if those were logged to the console (although it would be odd, because although I've been using Firefox since the beginning, I've *never* found the Console to be useful for solving anything), but I could find nothing in there about the problem. It wouldn't surprise me if the "Report This Error" button had some details, but there's no facility for displaying the contents of that error report, which, in this case, would be far mor useful to me than it would be to the website owners (in this case, you people).
Remember, too, that having some way of displaying the problem details would reduce the number of useless bug reports on it (including this one).

Comment 4

[Nickolay_Ponomarev]

This comment is about the specific subtype of the "Secure connection failed" error page, the one that has "The connection to %S was interrupted" text immediately below the heading. I'm not sure what other text can appear there, but the screenshot in comment 0 also has the "interrupted" message.

Looks like this was added in bug 1112399 (before in such case a simple "This connection was reset/interrupted" page was shown):
http://hg.mozilla.org/mozilla-central/annotate/73e42f528ee6/docshell/base/nsDocShell.cpp#l5176

I gather some servers interrupt the connection when they see the client request a TLS version they don't like. Or a server may interrupt a connection for a different reason -- there's no way to know other than to attempt to communicate with the server using a different version of TLS/SSL (which the user can control through security.tls.version.{min,fallback-limit,max}).

If my understanding is correct, the use of nssFailure2 page here seems wrong, as the "the authenticity of the received data could not be verified" bit is misleading and there's no indication this could be due to server being busy or not supporting the TLS version(s) we tried.

Instead I think we should show a separate kind of error page:

-----
== Secure connection interrupted == (new header to make this easily distinguishable from other Secure Connection Failed errors)
[netInterrupt] The connection to %S was interrupted while the page was loading.

[sharedLongDesc]
* The site could be temporarily unavailable or too busy. Try again in a few moments.
* If you are unable to load any pages, check your computer's network connection.
* If your computer or network is protected by a firewall or proxy, make sure that &brandShortName; is permitted to access the Web.
[new text]
* The site could interrupt the connection because of an incompatibility. Please contact the website owners to inform them of this problem.
-----

There's not much information to report to the user in this case (other than the SSL/TLS version(s) we tried).

It looks like you can use this in the Browser Console <https://developer.mozilla.org/en-US/docs/Tools/Browser_Console> to see the data (apart from the host/port) that is sent in the report:
gBrowser.docShell.failedChannel.securityInfo.QueryInterface(Ci.nsITransportSecurityInfo)

In the connection reset case all it contains (for me) is: "An error occurred during a connection to ****.Encountered end of file(Error code: pr_end_of_file_error)"

Comment 5

[Jesse Ruderman]

I hit this today, trying to load a huge file (ActorsParent.cpp) from DXR. Confusing to get "Secure connection failed" and "Report this Error" for a connection reset, since that's usually not a TLS problem.

Comment 6

[Anurag Goyal]

Is this actively worked or any possibility this will take priority - Seemingly this blocks bug 1220395, which i am seeing consistently on OSX 10.6.8.

Comment 7

[Ron Murray]

Can somebody please take a look at this again, and do something rather than just pontificating about it? 

I'd (again?) note that contacting the website owners about the "problem" is not going to happen if all I have to tell them is that "Firefox says it doesn't work". They'd just laugh at me, and rightly so.

@Jesse Ruderman: I suspect that when it says "the connection was reset", it means "Firefox reset the connection because it doesn't trust the certificate".

Comment 8

[Ron Murray]

Here's a suggestion: at least show us the offending SSL certificate. That might give us a clue as to what's going on.

Comment 9

[Masatoshi Kimura [:emk]]

Attachment: 1195370_stop_detecting_tls_intolerance

This patch will effectively backout a bug 1112399 change. More and more false positives are detected because more and more servers fixed TLS intolerance. I believe the bug 1112399 change has more harm than good now.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So if we back that out... what will the error page actually say, and will it be in any way actionable?

Or is this just about going back to "connection was interrupted" without any more information?  That doesn't seem like if would fix the bug as reported (which _was_ in fact a TLS intolerance case).

Comment 11

[Masatoshi Kimura [:emk]]

Comment on attachment 8745622 [details] [diff] [review]
1195370_stop_detecting_tls_intolerance

(In reply to Boris Zbarsky [:bz] from comment #10)
> Or is this just about going back to "connection was interrupted" without any
> more information?

Yes.

> That doesn't seem like if would fix the bug as reported
> (which _was_ in fact a TLS intolerance case).

Mmm, I'll implement comment #4 instead of this patch, then.

Comment 12

[:Cykesiopka]

emk: FYI, it looks like Bug 1252068 is also filed on this, so you probably want to coordinate with I guess :past.

Comment 13

[:Cykesiopka]

Looks like someone has been assigned to Bug 1252068.