Security:Renegotiation

The purpose of this document is to summarize security issue CVE-2009-3555 (a man-in-the-middle vulnerability in the TLS/SSL protocol) which applies to SSL/TLS/https/etc., to describe what action has been taken in Mozilla, and to describe what action other parties should take.

Background

In 2009, a flaw was discovered in the SSL/TLS protocol which is widely used in Internet applications, for example when accessing web content via an address prefixed with “https”.

This flaw could allow a ‘man-in-the-middle’ (MITM), to be able to inject data into a connection between an Internet client and an Internet server, and potentially allow an attacker to execute commands using the credentials of an authorised user, or to even collect authentication credentials of authorised users.

This security flaw has been labled CVE-2009-3555 and is (being) described in more detail:

• CVE-2009-3555
• National Vulnerability Database (CVE-2009-3555).

Because the flaw is not limited to any specific software implementation, but is rather a fundamental protocol design flaw, a lot of software using SSL/TLS is vulnerable.

Scope and Discussion

The attack is related to a SSL/TLS protocol feature called session renegotiation. The discovered vulnerability could be used to manipulate data received by a client or by a server. For example, a server is vulnerable if it is configured to allow session renegotiation, but is not yet using updated software.

One way to protect against the attack is to disable session renegotiation on the server. Hopefully, most Internet servers that do not yet support RFC 5746 have followed the recommendation and disabled the renegotiation feature.

Unfortunately, when a server is using the vulnerable SSL/TLS protocol version, it is impossible for the browser to know whether a site is protected or vulnerable (i.e whether session renegotiation is enabled or disabled on the server).

Because of this uncertainty, when using the existing SSL/TLS protocol versions, Firefox does not know whether a server is vulnerable. Firefox, therefore, is unable to determine whether a connection has been attacked.

An enhanced SSL/TLS protocol version has been finalized and is now published as RFC 5746.

In order to protect both browser users and servers from this attack, it is mandatory that both servers and clients update to newer software versions that do support RFC 5746.

Obviously it took some time to finalize the new protocol standard, have programmers write the code, release the updated software versions, ship it to customers and have them upgrade their servers. During that period of time, the only possible protection was to disable the session renegotiation feature in servers completely.

Unfortunately, many months after the new protocol has been standardized in February 2010, and many software vendors have released upgraded packages that do support RFC 5746, we see that many web sites are still running the older software versions, and this includes many major E-Commerce sites.

Hopefully all of them have really disabled the session renegotiation feature on their servers. Unfortunately, it's impossible for anyone else to verify.

Imagine an administrator at a major E-Commerce site, still running old software versions, installed some older version of a configuration file and at the same time accidentally re-enabled the session renegotiation. There wouldn't be any noticeable consequences. They site would still work as before, but suddenly the server and user's information become vulnerable again.

Because of this uncertainty and risk associated with running old SSL/TLS software, it is strongly recommended that all servers and clients are upgraded to software that supports RFC 5746 as soon as possible.

While most modern browser software has been upgraded to support RFC 5746, and upgrading the browsers is a mandatory action, upgrading the browsers is not sufficient! A verified protection against the attack requires both browsers and servers to upgrade.

As soon as a critical mass of servers has been upgraded to support RFC 5746, the browsers can start to assist users in discovering questionable servers and potentially vulnerable servers more easily.

Action

In order to ascertain that SSL/TLS sessions are protected, Internet deployments using SSL/TLS must be upgraded to support the new protocol enhancement described in RFC 5746.

Firefox has started to support this new protocol version in its experimental version since February 8th, 2010. By now the stable software versions made available by Mozilla support it, too.

Unfortunately, because of the complexity of the flaw and the need to get most of the world to upgrade their servers, it's a tough decision how Firefox should act.

As of February 2010, it would be useless to show a warning indicator to Firefox users in the chrome, because users would be shown warnings for 99·9% of SSL/TLS sites. It would cause confusion among users, and would teach them to ignore this warning, and possibly other similar-looking warnings.

We'd like to wait until a significant percentage of the web has been upgraded to the new protocol version, before we start to show warnings for those servers that still haven't upgraded.

(Update: Unfortunately, as of December 2010, we feel this milestone has still not been reached. Too many servers still haven't upgraded.)

However, while we wait for most of the web to upgrade, software testers need to know whether a site is vulnerable or not, and evangelists want to push server operators to upgrade their systems.

Therefore Firefox (and other Mozilla products) log information about “potentially vulnerable” servers to the Error console using the message "<site> : server does not support RFC 5746, see CVE-2009-3555".

You still get this warning for many servers. Please use this information to discover which sites have not yet been upgraded, and who can not be verified by the client to be immune against the attack.

Control

This section describes the behaviour of Firefox (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 about it.

Should Mozilla detect that a server asks the Mozilla client to perform a renegotiation on an existing connection, Mozilla may reject or accept this request, depending on the server software and depending on the configuration of the Mozilla client (e.g. Firefox).

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

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:

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 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 version
• 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 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

This preference was removed in Firefox 38. See bug 1123020.

security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref

Current default value: DEPENDS, see end of section

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.

Regarding default values:

• current development versions (including Firefox 4 beta) use “false”.
• The stable releases 3.5.9 and 3.6.2 use “true”.
• It's not yet decided which default value will be used for the stable Firefox 4 release.
• This preference was removed in Firefox 38. See bug 1123020.

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 utilises the old protocol version, not yet supporting the new, enhanced protocol version(s).

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 should be noted that this indicator isn't of much help with regards to state of the connection used to retrieve the content. When you see the indicator, it's already “too late”, as a connection to that server has already been established and an attack may have already occurred.

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 upgrade Web servers (by discovering servers using questionable versions, 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 reject all connection attempts to servers that are still using the old SSL/TLS protocol and 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 (initial) writing, this would break nearly all secure sites on the web. (Update: As of December 2010, this still applies for a majority of web sites.)

Eventually, if enough sites have been upgraded to the new protocol versions, this preference will be set to “true” by default.

Further ideas

security.ssl.treat_unsafe_renegotiation_as_broken and security.ssl.treat_unsafe_renegotiation_as_broken_hosts as per Bug 554594 – Alerts on CVE-2009-3555 TLS Renegotiation in Error Log — Comment #2