Last month, a vulnerability in SSL and TLS was announced. Almost immediately thereafter, it was successfully exploited to obtain Twitter account passwords. The vulnerability affects most existing implementations of SSL 3.x and TLS 1.x in existing https web servers and browsers, but also in other servers that use SSL, such as IMAPS, SMTPS, NNTPS (snews), and others.
The vulnerability lies in a seldom-used feature of SSL known as renegotiation. Most servers have no real need for renegotiation, and for them, the simplest solution is:
- disable it altogether -- if they can.
But some SSL implementations have no way to disable it, and need a patch to be able to do so. Such a patch is now available for numerous SSL/TLS libraries, especially the open source ones.
And some servers need and actively use SSL renegotiation. They're now faced with a more difficult decision. They can choose to:
- do nothing and continue to live with the vulnerability, or
- disable renegotiation until the IETF standardizes a new form of renegotiation, that is implemented by all major server and browser vendors, and is deployed to all servers, desktops and laptops, and hope it doesn't take too long, or
- refactor their sites to eliminate the dependence on renegotiation forever, perhaps by splitting the site into multiple sites (or multiple ports on the same host), using redirection instead of renegotiation.
How will your https site address the SSL renegotiation vulnerability?