Example site (as of this writing) : https://www.discover.com/ The attached screenshot isn't the front page of the site, but the same error is visible on the front page as well, without logging in. When I click the "More information" button, there is no "View certificate" button at all, making it impossible to find out what the real error is from the GUI. I only found it by looking at the console. I have security.ssl.treat_unsafe_negotiation_as_broken set to true, so I guess the main issues here are the misleading doorhanger which doesn't tell the real error, and the lack of a View Cert button on the security dialog.

with security.ssl.treat_unsafe_negotiation_as_broken set to false, the EV indicator returns and View Certificate is again available in the security dialog.

11:50:41.828 www.discover.com : server does not support RFC 5746, see CVE-2009-35551 Looks like discover.com doesn't support secure renegotiation. What is probably going on here is that with security.ssl.treat_unsafe_negotiation_as_broken set to true, the connection is considered broken, so no security information is exposed. This is probably the wrong thing to do, as it makes it difficult to diagnose that and other problems. See also bug 883674 regarding other problems with how we notify when sites don't support secure renegotiation.

I believe Dave said on IRC he was using Firefox Dev Edition (Aurora) which is probably still Gecko 36 after this week's release, but might be 37 already. I can load the discover site whichever way the security.ssl.treat_unsafe_negotiation_as_broken is set. That setting should only affect the display of the lock icon (e.g. you won't get a lock, let alone a green one), not prevent any loads. Unfortunately when the lock isn't displayed then the View Certificate button isn't either (though sometimes you can get there through Page Info). The screenshot you show is exactly what I expect to see if you set the pref (treat as broken) to true. The idea was to set it one of these days so we can ease into the stricter "require_safe_negotiation" pref. When I set security.ssl.require_safe_negotiation to true then the site won't load at all, but the error page is appropriate "An error occurred during a connection to www.discover.com. Peer attempted old style (potentially vulnerable) handshake. (Error code: ssl_error_unsafe_negotiation)" This doesn't appear to have anything to do with the SHA1 cert, though if we follow Google's lead we may one day start treating SHA1 certs as "broken" also. IOW I think this is basically a dupe of bug 883674, that we're not effectively letting people know /why/ we're treating the UI as broken. The fact that your pref asked us to treat it as broken and so we are seems to be working perfectly :-). But this kind of UI/communication issue is probably a large part of why we haven't pushed to make this the default setting.

The changes in bug 1126413 should partly address this (by making the "View Certificate" button available). We would still need to add some wording or other indication that the usage of insecure negotiation is the issue (maybe in the security pane in the network monitor?)

As mentioned in comment 3 and comment 4, per the current summary, this bug is basically a dupe of others. Like those comments suggest, let's make this bug about the confusing UI.

This is what the Control Center and the "More Information" window say on Firefox 42 and 43 when enforcing security.ssl.treat_unsafe_negotiation_as_broken.