7
edits
Changes
many minor changes: linkified terms, scanability/usability enhancements, grammar/readability improvemets using clearer language, code-level corrections, typography corrections
The purpose of this page document is to summarize security issue [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555 that CVE-2009-3555] which applies to [[Security:TLS|SSL/TLS/https/etc.]], and to describe what actions are being taken in Mozilla and Firefox productssoftware.
<bstrong>The information on contained within this page article is preliminary, and is subject to change.</bstrong>.
==Background==
In 2009 , a flaw was discovered in the SSL/TLS protocol which is widely used in Internet applications, for example when accessing web pages using the "https" methodcontent via an address prefixed with “https”.
This flaw could allow a MITM (‘[http://en.wikipedia.org/wiki/Man-in-the-middle_attack 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 Internet authorised user, or to even steal collect authentication credentialsof authorised users.
This security flaw has been labled <cite>CVE-2009-3555 </cite> and is (being ) described in more detail at :* [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 and CVE-2009-3555]* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555National Vulnerability Database (CVE-2009-3555)].
Because the flaw is not specific limited to any specific software productimplementation, but is rather a fundamental protocol design flaw, a lot of software using SSL/TLS is vulnerable.
==Scope==
In order to allow the attack to work, a SSL/TLS protocol feature must be enabled which is called <cite>session renegotiation</cite>.
One way to protect against the attack is to disable this feature. Hopefully ,most Internet servers have followed the recommendation and turned disabled the renegotiation feature off.
<bstrong>Unfortunately, when using the old present, flawed SSL/TLS protocol version, it is not possible to know determine whether a site is protected or vulnerable.</bstrong>
Because of thisuncertainty, when using the old existing SSL/TLS protocol versions, Firefox does not know whether a server it talks to a communicates with is vulnerable server. Firefox does not know , therefore, is unable to determine whether a connection has been attacked.
An [http://www.rfc-editor.org/authors/rfc5746.txt enhanced SSL/TLS protocol version ] is currently being finalized and is soon to be published as an RFC, currently located at: [http://www.rfc-editor.org/authors/rfc5746.txtRFC 5746].
As soon as both parties of an SSL/TLS session (e.g. Firefox and an Internet Servera Web server) are using the new protocol version they will be protected against the attack, and Firefox can be sure , again, assume the connection is protected.
==Action==
In order to ascertain that SSL/TLS sessions are protected, most Internet installations using this protocol must be upgraded to support the new protocol version (currently <cite>draft-rescorla-tls-renegotiation</cite>).
Firefox has started to support this new protocol version in its experimental version since February 8th, 2010. Mozilla will include support in stable product versions as soon as possible.
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 today (February 2010-02-08) , it would be useless to show a warning indicator to Firefox users in the chrome, because we'd show users would be shown warnings for 99.999·9% of the webSSL/TLS sites. It would cause confusion for among users , and would teach them to ignore the 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 protocolversion, before we start to show a warning for those (few) servers that 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" “potentially vulnerable” servers to the Error console.
In the beginning you will receive warnings for many servers. The idea to log this information to the console is experimental, we may disable it if there are too many complaints or if it's causing too much distraction.
However, it would be preferable to keep the information, as the world really needs to be made aware and be reminded to upgrade.
A test server that supports the new protocol version can be accessed at https://ssltls.de/
==Control==
* Mozilla will start the initial negotiation
* it will advertise support for the new protocolversion
* 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
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:
===<code>security.ssl.renego_unrestricted_hosts</code>===
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: <code>www.dns1.com,mail.dns2.com</code>
===<code>security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref</code>===
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"“false”, and instead populate preference security.ssl.renego_unrestricted_hosts with a list of hosts that require the exception.
The preference carries "“<code>temporarily_available_pref" </code>” in its name, as it's supposed to go away later.
Regarding default values:
* The development version of Firefox (3.7-pre) uses "false"“false”.* The stable releases 3.5.9 and 3.6.2 use "true"“true”.* As soon as a sufficient amount of servers had a chance to upgrade, the default in stable releases will be switched to "false"“false”, too.
===<code>security.ssl.treat_unsafe_negotiation_as_broken</code>===
Current default value: false
This preference can be used to achieve visual feedback when connecting to a server that still uses utilises the old softwareprotocol version, not yet supporting the protocolsnew, enhanced protocol version(s).
When set to true, when connecting to such a server, Firefox will warn about "broken security" “broken security” by displaying a red/broken padlock in its status bar.
It shall should be noted that this indicator isn't of much help with regards to state of the shown pageconnection used to retrieve the content. When you see this the indicator, it's already "too late"“too late”, as a connection to that server has already taken place been established and an attack may have already taken placeoccurred.
However, it's still helpful to have this indicator, as it raises awareness of servers that still need to be upgraded. "Evangelists" “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 upgrade Web servers (by discovering old servers using vulnerable 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.
===<code>security.ssl.require_safe_negotiation</code>===
Current default value: false
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" “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" “true” by default.
== Further ideas ==
''<code>security.ssl.treat_unsafe_renegotiation_as_broken</code>'' and ''<code>security.ssl.treat_unsafe_renegotiation_as_broken_hosts</code>'' as per [https://bugzilla.mozilla.org/show_bug.cgi?id=554594#c2 Bug 554594 – Alerts on CVE-2009-3555 TLS Renegotiation in Error Log — Comment #2]
