Firefox 5 unable to renegotiate on SSL socket

When trying to login to my account at myopenid.com with SSL certificate I get error:

Secure Connection Failed
          An error occurred during a connection to www.myopenid.com.
Renegotiation is not allowed on this SSL socket.
(Error code: ssl_error_renegotiation_not_allowed)

Using mozilla binary
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

On https://developer.mozilla.org/NSS_3.12.6_release_notes
see the section titled SSL3 & TLS Renegotiation Indication Extension

the default setting is
# [2|r|R]: SSL_RENEGOTIATE_REQUIRES_XTN (default)
Only allows renegotiation if the peer's hello bears the TLS renegotiation_info extension. This is the safe renegotiation.

Downstream distributions can opt to change the default to
[3|t|T]: SSL_RENEGOTIATE_TRANSITIONAL
Disallows unsafe renegotiation in server sockets only, but allows clients to continue to renegotiate with vulnerable servers. This value should only be used during the transition period when few servers have been upgraded.

Is this using the Mozilla-produced binary or a Red Hat one?

Kai: Does Mozilla have different renegotiation settings between Firefox 4 and the 3.6 branch? I know we talked about getting more strict later, but Firefox 4 probably isn't later enough.

I spoke to Matej online earlier and he said he using Mozilla's iirc.

(In reply to comment #2)
> Is this using the Mozilla-produced binary or a Red Hat one?

This is 4.0b6 x86_64 from ftp.mozilla.org

Matej: thanks for the bug report. https://www.myopenid.com
does not support the TLS renegotiation_info extension. This
is why Firefox reports the ssl_error_renegotiation_not_allowed
error when https://www.myopenid.com requests old-style (insecure)
renegotiation.

Please submit a bug report to the website administrator of
https://www.myopenid.com to have their SSL implementation upgraded.

In Firefox, you can work around this server security problem as follows.
1. Type about:config in the location bar.
2. Type security.ssl.renego_unrestricted_hosts in the Filter field
3. Add www.myopenid.com to the value of the
   security.ssl.renego_unrestricted_hosts preference.

We need to document the TLS Renegotiation prefs on MDC so SUMO folks have somewhere to point people having problems. These prefs are currently documented at https://wiki.mozilla.org/Security:Renegotiation but in a developer-oriented fashion.

The basic functionality was added to Firefox 3.6.2 and 3.5.9

What is new in Firefox 4 is the default for the pref security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref

The setting is 'true' in the older branches and 'false' (safe) in FF4.

In the default settings the stable branches CAN renegotiate safely if the site supports the updated protocol. On the trunk we REQUIRE safe renegotiation. This will break some sites.

This still doesn't protect users against the more likely initial-negotiation attack (the one used against Twitter, for example). Until we turn on one or both of the other two prefs users have to rely entirely on the site to disable renegotiation or implement the new protocol.

The next step would be to disable positive SSL notification for broken sites with the pref security.ssl.treat_unsafe_negotiation_as_broken -- but currently too many sites are broken (including about a third of SSL sites that appear to have disabled renegotiation and are probably safe, but the browser can't tell).

The last step would be to enable the pref security.ssl.require_safe_negotiation and reject connections to any site without support for the new protocol. That will take a while if the SSLv2 experience teaches us anything.

Reopening the bug for Mr. Firefox (Johnathan) to agree documenting the new behavior is good enough and so Sheppy notices the dev-doc-needed (not sure his queries see closed bugs).

It seems like this is not a product blocker but we should have the docs ready for FF4. Does this sound reasonable? How can we get it out of the nomination queue.

It's on the list of things to document and will be gotten done when we can.

Johnath, would appreciate your weigh-in here as well - bad tradeoff here between "being insecure" and "being compatible." My feeling is that this is WONTFIX with a follow-up to the various sites explaining why they won't work in Firefox 4.

Agreed?

Agreed. I hate the compat hit, but this problem has been known for a while, we winced and took the compat path on 3.5/3.6, we have a pref for truly broken scenarios in 4.0.

Tagging this with user-doc-needed. I also think it should be WONTFIX, but will defer to an actual PSM peer (WTC, Kai?) instead of using my quasi-peer status here. :)

I agree with WONTFIX

I'm glad we all agree on the more secure path.

Hello, is there a final decision about the default value of this parameter ?

Most of the ssl site are not yet upgraded to support the ssl fix.
So there will be a lot of trouble for the client using services which lessen friendlyness of some application.

I think it's important for firefox adoption that things are in touch with the reality and I don't think it's the responsability of firefox to impose this ssl fix.