When the TLS Renego vulnerability was discovered a year ago (November 4, 2009), many SSL/TLS server vendors rushed out a temporary workaround to mitigate the threat against servers: Disable renegotiation by default on the server.
This had the benefit of preventing the easiest way of using this new attack vector: Inserting a request into the server's command stream, before letting the client take over and receive the malicious result.
It did not, however, help clients if the attack was staged against them, but such an attack is more difficult to accomplish and does not look any different from an ordinary certificate replacement attack, except when the server requires client certificate authentication.
Since the real Renego protocol patch (the RI Extension, RFC 5746) was released in February 2010, and Opera 10.50 was released with this update, I have occasionally received complaints from users and system administrators about Opera's security information item "The server does not support secure TLS renegotiation", claiming that we should not display that for their server because they have added the above mentioned workaround. One of the references used for these was Ivan Ristic's SSLlabs tester. Ivan has since updated the site, and also posted an article about this topic
At least two server vendors have used the same argument about why they do not need to immediately ship an update supporting the RI extension.
I suspect that this perception, that the workaround is "sufficient", is delaying the deployment of updates with the RI-extension, so it is time to set the record straight:
Disabling server-side renegotiation was a quick & dirty, and very temporary, workaround deployed while there was no other, and more secure options available, in order to mitigate the discovered problem. It was never meant to be a permanent solution, nor does it provide any real security.
One reason for this is an aspect of the Renego-problem that many forget: The attack can be used against the client, too, not just the server! Admittedly, the client-side attack is more difficult to carry off, and will usually be indistinguishable from a normal Man-In-The-Middle attack with a fake certificate, but there might still be situations where such an attack can yield results for an attacker, even against a server that has disabled renegotiation, because the clients cannot disable that functionality.
But the other reason this is a significant problem is that the client cannot know that the server has implemented the workaround! It have to treat any server that does not return the RI-extension as if it is unsecure. Even if the client should waste time probing the server to "confirm" that the server refused to renegotiate, the result would be inconclusive, for two reasons:
- An attacker can fake the response, particularly the aggressive "close the connection" response. So the client might think the server is "secure", while it isn't.
- Some servers do not accept a client-initiated renegotiation, but many servers, particularly ones requiring client certificate authentication, will tell the client that it wants to renegotiate the connection. Such server-initiated renegotiation is usually triggered in response to specific queries to the server, and these server-specific triggers are generally unknowable to a client trying to perform a general capability test of the server. So, once again, a client might think that the server is "secure", while it isn't.
For these reasons, as well as the fact that such testing would waste time, no client have, to my knowledge, realistically considered probing the server. Doing so would be a waste of time and resources and would obtain a meaningless result.
Even worse, however, is that a recently released client that support the RI-extension cannot know whether the connection with an unpatched server has been intercepted and is being manipulated, because without the RI extension there is no way to tell securely that the client and server have only been talking to each other, and not also an additional party.
Therefore, all server and OS vendors that still haven't released a Renego-patch for all their maintained versions (beta versions do not count): It is time to get down from the fence and release a patch. Now!
:knight: