Changes

Jump to: navigation, search

Security:Renegotiation

5,329 bytes added, 12:41, 8 February 2010
Control
==Control==
This section describes the behaviour of Firefox introduces multiple hidden (and other Mozilla software) when talking to Internet servers, which may or may not (yet) support the new protocol enhancement, and the preferences users can set to control the behaviour of the Mozilla client software. When starting a handshake for an SSL 3 or a TLS 1 connection, Mozilla will advertise its support for the new renegotiation extension, so the server can know aboutit. Should Mozilla detect that a server asks the Mozilla client to perform a renegotiation on an existing connection, Mozilla may reject or accept this reject, depending on the server software and depending on the configuration of the Mozilla client (e.g. Firefox). <b>In order to understand the following preferences to control Mozilla's behaviour, it's important to understand and carefully distinguish the terms "negotiation" and "renegotiation".</b> Negotiation refers to the initial handshake between client and server. Renegotiation refers to an attempt to repeat the negotiation on an existing connection. In order to clarify why this distinction is relevant, let's repeat one property of the attack scenarios using the old protocol versions:config The attack requires a renegotiation. However, a renegotiation may happen between a MITM and a server, while the Mozilla client is under the impression that the connection it is still at the stage of the initial negotiation. Only the use of the new protocol versions on both sides of a connection can clarify this and ascertain to be safe against the attack. Now let's describe the new default behaviour that was introduced in experimental mozilla-central nightly versions on 2010-02-08: * Mozilla will start the initial negotiation* it will advertise support for the new protocol* it will allow the connection regardless of server protocol support* should the server (or a MITM) request renegotiation, Mozilla will terminate the connection with an error message The above defaults may break some client/server environments where a Server is still using old software and requires renegotiation. This is often being used when a server asks a client to present a certificate for authentication or when a different level of encryption strength is being enforced for certain resources. (When the security flaw became public, it has been recommend to strictly separate all content and servers into separate servers, each using homogeneous authentication and security preferences , but not all deployments may have followed this security recommendation.) In order to give such environments a way to control how keep using Firefox (et.al.) to connect to their vulnerable server infrastructure, the following preferences are available: ===security.ssl.renego_unrestricted_hosts=== Empty by default. This string preference is a list oft host names, separated by comma (,) where renegotiation may be performed, even when using the old vulnerable protocol. No wildcards are supported. Example: www.dns1.com,mail.dns2.com ===security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref=== Current default value: false It's not desirable to set this to true, as it completely disables the new protection mechanisms. However, in controlled environments where many old new server must be accessed, this may be used. It's highly recommended to leave this at the default value "false", and instead populate preference security.ssl.renego_unrestricted_hosts with a list of hosts that require the exception. The preference carries "temporarily_available_pref" in its name, as it's supposed to go away later. ===security.ssl.treat_unsafe_negotiation_as_broken=== Current default value: false This preference can be used to achieve visual feedback when connecting to a server that still uses old software, not yet supporting the protocols. When set to true, when connecting to such a server, Firefox will warn about "broken security" by displaying a red/broken padlock in its status bar. It shall be noted that this indicator isn't of much help with regards to state of the shown page. When you see this indicator, it's already "too late", as a connection to that server has already taken place and an attack may have already taken place. However, it's still helpful to have this indicator, as it raises awareness of servers that still need to be upgraded. "Evangelists" (for a better web) should ask server operators to perform a server software upgrade in order to protect users and their data. If you read this page and understand this issue, you are encouraged to switch this pref to true and help with the process to get the web upgraded (by discovering old servers and asking operators to upgrade). Note: No visual warnings are yet available for other Mozilla software) . However, Mozilla clients will produce warnings on the error console for sites that are potentially vulnerable. ===security.ssl.require_safe_negotiation=== Current default value: false This pref controls the behaviour during the initial negotiation between client and server. If set to true, a Mozilla client will behave when talking reject all connection attempts to servers that do not yet support are still using the new old SSL/TLS protocol enhancementand which might be vulnerable to the attack. Setting this preference to "true" is the only way to guarantee full protection against the attack. Unfortunately, as of time of writing, this would break nearly all secure sites on the web. Eventually, if enough sites have been upgraded to the new protocol versions, this preference will be set to "true" by default.
Confirm
563
edits

Navigation menu