7
edits
Security:Renegotiation: Difference between revisions
Jump to navigation
Jump to search
many minor changes: linkified terms, scanability/usability enhancements, grammar/readability improvemets using clearer language, code-level corrections, typography corrections
m (→Further ideas: clarified link text) |
(many minor changes: linkified terms, scanability/usability enhancements, grammar/readability improvemets using clearer language, code-level corrections, typography corrections) |
||
| Line 1: | Line 1: | ||
The purpose of this | The purpose of this document is to summarize security issue [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555 CVE-2009-3555] which applies to [[Security:TLS|SSL/TLS/https/etc.]], and to describe what actions are being taken in Mozilla and Firefox software. | ||
< | <strong>The information contained within this article is preliminary, and is subject to change.</strong> | ||
==Background== | ==Background== | ||
In 2009 a flaw was discovered in the SSL/TLS protocol which is widely used in Internet applications, for example when accessing web | 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 | This flaw could allow a ‘[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 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 | This security flaw has been labled <cite>CVE-2009-3555</cite> and is (being) described in more detail: | ||
* [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 CVE-2009-3555] | |||
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555 National Vulnerability Database (CVE-2009-3555)]. | |||
Because the flaw is not | 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== | ==Scope== | ||
In order to allow the attack to work, a SSL/TLS protocol feature must be enabled which is called session renegotiation. | 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 | One way to protect against the attack is to disable this feature. Hopefully ,most Internet servers have followed the recommendation and disabled the renegotiation feature. | ||
< | <strong>Unfortunately, when using the present, flawed SSL/TLS protocol version, it is not possible to determine whether a site is protected or vulnerable.</strong> | ||
Because of this, when using the | Because of this uncertainty, when using the existing SSL/TLS protocol versions, Firefox does not know whether a server it communicates with is vulnerable. Firefox, therefore, is unable to determine whether a connection has been attacked. | ||
An enhanced SSL/TLS protocol version is currently being finalized and is soon to be published as | 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 [http://www.rfc-editor.org/authors/rfc5746.txt RFC 5746]. | ||
As soon as both parties of an SSL/TLS session (e.g. Firefox and | As soon as both parties of an SSL/TLS session (e.g. Firefox and a Web server) are using the new protocol version they will be protected against the attack, and Firefox can, again, assume the connection is protected. | ||
==Action== | ==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 (currently draft-rescorla-tls-renegotiation). | 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. | 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. | ||
| Line 35: | Line 37: | ||
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. | 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 | 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, before we start to show a warning for those (few) servers that still haven't upgraded. | 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 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. | 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 | Therefore Firefox (and other Mozilla products) log information about “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. | 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. | ||
| Line 47: | Line 49: | ||
However, it would be preferable to keep the information, as the world really needs to be made aware and be reminded to upgrade. | 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 can be accessed at https://ssltls.de/ | A test server that supports the new protocol version can be accessed at https://ssltls.de/ | ||
==Control== | ==Control== | ||
| Line 72: | Line 74: | ||
* Mozilla will start the initial negotiation | * Mozilla will start the initial negotiation | ||
* it will advertise support for the new protocol | * it will advertise support for the new protocol version | ||
* it will allow the connection regardless of server protocol support | * 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 | * should the server (or a MITM) request renegotiation, Mozilla will terminate the connection with an error message | ||
| Line 82: | Line 84: | ||
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: | 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=== | ===<code>security.ssl.renego_unrestricted_hosts</code>=== | ||
Empty by default. | Empty by default. | ||
| Line 88: | Line 90: | ||
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. | 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 | Example: <code>www.dns1.com,mail.dns2.com</code> | ||
===security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref=== | ===<code>security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref</code>=== | ||
Current default value: DEPENDS, see end of section | Current default value: DEPENDS, see end of section | ||
| Line 96: | Line 98: | ||
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 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 | 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 | The preference carries “<code>temporarily_available_pref</code>” in its name, as it's supposed to go away later. | ||
Regarding default values: | Regarding default values: | ||
* The development version of Firefox (3.7-pre) uses | * The development version of Firefox (3.7-pre) uses “false”. | ||
* The stable releases 3.5.9 and 3.6.2 use | * The stable releases 3.5.9 and 3.6.2 use “true”. | ||
* As soon as a sufficient amount of servers had a chance to upgrade, the default in stable releases will be switched to | * As soon as a sufficient amount of servers had a chance to upgrade, the default in stable releases will be switched to “false”, too. | ||
===security.ssl.treat_unsafe_negotiation_as_broken=== | ===<code>security.ssl.treat_unsafe_negotiation_as_broken</code>=== | ||
Current default value: false | Current default value: false | ||
This preference can be used to achieve visual feedback when connecting to a server that still | 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 | 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 | 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. | 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 | 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 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. | 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=== | ===<code>security.ssl.require_safe_negotiation</code>=== | ||
Current default value: false | Current default value: false | ||
| Line 129: | Line 131: | ||
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. | 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 | 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 | Eventually, if enough sites have been upgraded to the new protocol versions, this preference will be set to “true” by default. | ||
== Further ideas == | ==Further ideas== | ||
''security.ssl.treat_unsafe_renegotiation_as_broken'' and ''security.ssl.treat_unsafe_renegotiation_as_broken_hosts'' 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] | ''<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] | ||