Security:Renegotiation: Difference between revisions

Security:Renegotiation (view source)

Revision as of 12:45, 10 December 2010

2,024 bytes added , 10 December 2010

update scope to latest developments and add discussion

Kaie

Confirmed users

563

edits

@@ Line 15: / Line 15: @@
 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 and Discussion==
-In order to allow the attack to work, a SSL/TLS protocol feature called <cite>session renegotiation</cite> must be enabled on the server.
+The attack is related to a SSL/TLS protocol feature called <cite>session renegotiation</cite>. 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.
-<strong>Unfortunately, when using the present, flawed SSL/TLS protocol version, it is not possible to determine 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 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.
+Because of this uncertainity, 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] is currently being finalized and is soon to be published as [http://www.rfc-editor.org/authors/rfc5746.txt 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.
-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.
+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 <cite>session renegotiation</cite> 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 <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 noticable consequences. They site would still work as before, but suddenly the server and user's information become vulnerable again.
+Because of this uncertainity 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.
+Let's make sure we eliminate this uncertainity. 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==