Bug 1084025 disabled TLS insecure fallback, which breaks some (badly configured) sites. Unfortunately the error message displayed when these sites break is really rather generic - and as a result, I wasted 90 minutes of Mozilla time filing the initial bug, comparing nightly vs chrome, trying clean profiles, using mozregression (which broke when it reached the inbound bisection part), manually reading the m-c merge pushlog to find the relevant change, reading up on bug 1084025 etc. Please can we include a specific mention of the reason why the connection failed and link to more information - eg: "This site uses an insecure version of TLS, please see [this FAQ]." The current message: """ Secure Connection Failed The connection to identity.virginmedia.com was interrupted 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. """

[Tracking Requested - why for this release]: Bug 1084025 (which can break sites) landed in Firefox37, but the current error message isn't clear (to the point where as a Mozilla employee it still took ages to figure out why a site wasn't working). Without a clarification to the error message, this is going to cause significant confusion on beta/release, since people won't know (a) what to say to the site owners about the issues with their TLS configuration, (b) that they should even file a Tech Evang bug and/or get the site added to the whitelist (or even that there is a whitelist).

I see there is a link tucked away under "Report this error" called "learn more..." however: (a) it links to a page that currently only displays: "This article doesn't have approved content yet." (b) it's too hidden - the reason (and link) should be on one of the main bullet points.,

I tried a more specific error message in bug 1112399, but Brian opposed the idea.

It will be definitely help to adding a bullet point for explaining insecure fallback.

Also I'm not sure if me hitting the issue for this site was supposed to be reported? I have telemetry enabled and hit this error several times in Dec/Jan (I just ended up using Chrome then and not filing a bug, thought it was some weird site issue and it would resolve itself) - but yet I see no whitelist entry has been added for it. Or was the telemetry only for counts and not domains?

IIRC telemetry can not send information such as domains due to privacy reasons.

The fix for this bug will require string changes, which we're too late in the cycle to accept. Brian - We deferred bug 1084025 to 37. Given the number of affected sites and this report, what do you think about deferring again to 38 and either updating the error message or working on reducing the number of affected sites (or both) in order to better prepare for this change?

(In reply to Ed Morley [:edmorley] from comment #0) > Please can we include a specific mention of the reason why the connection > failed and link to more information - eg: "This site uses an insecure > version of TLS, please see [this FAQ]." The TLS version fallback mechanism is (was) a heuristic that had many false positives. In fact, we suspect that the vast majority (maybe 75% or more) of the fallback attempts were false positives. Thus, if we use the same heuristic to show different error text, that error text will be wrong maybe 75% of the time or more. I think that would be even worse than the current situation. The current text is correct, if incomplete. Masatoshi is working on the whitelist mechanism which will make it so that very few users should ever encounter an error page for true version intolerance anyway, which would likely further increase the false positive rate--i.e. increasing the rate at which our heuristics would show the wrong message, if we were to fix this bug. Also, like Lawrence said, new error text would require localization changes, which would create pressure to push the feature back further. Normally, I wouldn't oppose bumping features like this back a release, but disabling the non-secure fallback logic is time-sensitive due to external factors, so I'd like to find ways to avoid it, if at all possible. So, I think it is better to spend more effort expanding Masatoshi's whitelist and WONTFIX this bug. However, I'm not the PSM module owner any more. I'd ask David what he thinks.

Why not put it in the release notes?

relnote-firefox is already requested in bug 1084025.

I'm clearing the tracking request for this bug based on comment 8. If this bug isn't resolved as wontfix, it still will be difficult to make this type of change in 37. This change will be more suitable for the current branch that is on m-c.

I think our effort is best spent making this "just work" for as many people as possible by default. That means broadening the whitelist and trying to find as many affected sites as possible. That said, these error pages could use some improvement in terms of informing users why the connection isn't working. This shouldn't block bug 1084025 - either the whitelist will be sufficient or we'll pull the change back to 38.

Sounds like there is a plan, happy to leave the decisions to you all - just wanted to raise awareness of the ambiguity for people outside or those who created the implementation, which sounds like it's been achieved :-)

I think bug 1273708 will address this on the front-end.