Changes

Jump to: navigation, search

Security:Renegotiation

2,024 bytes added, 12:45, 10 December 2010
update scope to latest developments and add discussion
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.
==Scopeand Discussion==
In order to allow the The attack is related to work, a SSL/TLS protocol feature called <cite>session renegotiation</cite> must . The discovered vulnerability could be enabled on the used to manipulate data received by a client or by a server. For example, a serveris 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 a server is using the present, flawed vulnerable SSL/TLS protocol version, it is not possible impossible for the browser to determine know whether a site is protected or vulnerable (i.e whether session renegotiation is enabled or disabled on the server).</strong>
Because of this uncertaintyuncertainity, 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 [http://www.rfc-editor.org/authors/rfc5746.txt enhanced SSL/TLS protocol version] is currently being <strong>has been finalized </strong> and is soon to be now published as [http://www.rfc-editor.org/authors/rfc5746.txt RFC 5746].
As soon as In order to protect both browser users and servers from this attack, it is mandatory that both parties 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 session (esoftware, it is strongly recommended that all servers and clients are upgraded to software that supports RFC 5746 as soon as possible.g. Firefox  While most modern browser software has been upgraded to support RFC 5746, and upgrading the browsers is a Web server) are using mandatory action, <strong>upgrading the new protocol version they will be protected browsers is not sufficient</strong>! A verified protection against the attack, requires both browsers and Firefox can, againservers 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, assume the connection is protectedbrowsers can start to assist users in discovering questionable servers and potentially vulnerable servers more easily.
==Action==
Confirm
563
edits

Navigation menu