Security:Renegotiation: Difference between revisions

Jump to navigation Jump to search
m
(removed "preliminary" warning)
Line 21: 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 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.
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 33: 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 noticable consequences. They site would still work as before, but suddenly the server and user's information become vulnerable again.
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 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.
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.


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.
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==
Confirmed users
596

edits

Navigation menu