Disabling SSL renegotiation is a crutch, not a fix

In the days that followed the discovery of SSL/TLS Authentication Gap, some sites (those that did not need renegotiation) were able to deal with the problem by disabling renegotiation in server code. With no support for renegotiation, gone was the danger of exploitation. Good for them.

The sites that did need renegotiation had to wait, first for the TLS working group to solve the issue on the protocol level, and then for their SSL library (or web server) vendors to support the enhancement. The TLS working group did a great job negotiating the fix. As for the vendors, some implemented the new feature quickly, some dragged their feet a little, and some (Debian) seem to refuse to fix the problem, leaving their users vulnerable.

To sum it up, today, almost a year after the initial public discovery, we have some servers that are still vulnerable, some that refuse to support renegotiation, and some that support the new standard for secure renegotiation.

So where is the problem, you might ask? If disabling renegotiation prevents exploitation, that’s surely a good thing? Well, it depends on how you look at things. Try to look at the problem through the eyes of a browser developer. I was actually prompted to write about this problem by Yngve Nysæter Pettersen, who’s part of Opera’s security group. Opera wants to protect its users, and for that to be possible they need to know if a particular server supports secure renegotiation. If a server does, Opera can happily renegotiate whenever necessary. But if a server does not support secure renegotiation, you can make an argument that Opera should refuse any renegotiation attempts.

The servers that support secure renegotiation indicate so during the SSL handshake phase, and everyone’s happy and secure. The issue is with the servers that disable renegotiation, because they provide no indication of their security status. Some are insecure, while some aren’t. Without knowing, browsers can’t do anything. They can perhaps only inconvenience users and force them to manually configure protection levels.

While it is possible to test for insecure renegotiation (SSL Labs does it), the test is indicative but not conclusive — there is no way to test for server-initiated renegotiation. Besides, it’s not reasonable to expect browsers to test every SSL site they encounter.

My point is those that disabled SSL renegotiation must nevertheless implement the proper fix as soon as it becomes available for their platform. Patching is slow enough as it is, and we don’t need any further distractions to slow us down.