Confirmed users
133
edits
Security:Renegotiation: Difference between revisions
Removed link to https://ssltls.de/ which is no longer an RFC 5746 test server.
(Removed link to https://ssltls.de/ which is no longer an RFC 5746 test server.) |
|||
| (7 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
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 [http://en.wikipedia.org/wiki/Transport_Layer_Security SSL/TLS/https/etc.], | 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] (a man-in-the-middle vulnerability in the TLS/SSL protocol) which applies to [http://en.wikipedia.org/wiki/Transport_Layer_Security SSL/TLS/https/etc.], to describe what action has been taken in Mozilla, and to describe what action other parties should take. | ||
==Background== | ==Background== | ||
| Line 23: | Line 21: | ||
<strong>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).</strong> | <strong>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).</strong> | ||
Because of this | 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 [http://www.rfc-editor.org/authors/rfc5746.txt enhanced SSL/TLS protocol version] <strong>has been finalized</strong> and is now published as RFC 5746. | An [http://www.rfc-editor.org/authors/rfc5746.txt enhanced SSL/TLS protocol version] <strong>has been finalized</strong> and is now published as RFC 5746. | ||
| Line 35: | Line 33: | ||
Hopefully all of them have really disabled the <cite>session renegotiation</cite> feature on their servers. Unfortunately, it's impossible for anyone else to verify. | Hopefully all of them have really disabled the <cite>session renegotiation</cite> 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 <cite>session renegotiation</cite>. There wouldn't be any | 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 <cite>session renegotiation</cite>. 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 | 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, <strong>upgrading the browsers is not sufficient</strong>! A verified protection against the attack requires both browsers and servers to upgrade. | While most modern browser software has been upgraded to support RFC 5746, and upgrading the browsers is a mandatory action, <strong>upgrading the browsers is not sufficient</strong>! 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== | ==Action== | ||
| Line 62: | Line 60: | ||
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. | 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== | ==Control== | ||
| Line 105: | Line 101: | ||
Example: <code>www.dns1.com,mail.dns2.com</code> | Example: <code>www.dns1.com,mail.dns2.com</code> | ||
This preference was removed in Firefox 38. See [https://bugzilla.mozilla.org/show_bug.cgi?id=1123020 bug 1123020]. | |||
===<code>security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref</code>=== | ===<code>security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref</code>=== | ||
| Line 120: | Line 118: | ||
* The stable releases 3.5.9 and 3.6.2 use “true”. | * 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. | * 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=1123020 bug 1123020]. | |||
===<code>security.ssl.treat_unsafe_negotiation_as_broken</code>=== | ===<code>security.ssl.treat_unsafe_negotiation_as_broken</code>=== | ||
| Line 145: | Line 144: | ||
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 “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. | 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. | Eventually, if enough sites have been upgraded to the new protocol versions, this preference will be set to “true” by default. | ||