Renego patched servers: A long-term interoperability time bomb brewing

As mentioned in a security group article a few weeks ago, over the past few months, we have been probing a large number of SSL/TLS servers to follow the adoption of servers that have fixed the TLS Renego vulnerability.

Over the past three months, about 12% of the tested servers have been updated to support the new TLS Extension that was developed to fix the issue. Extrapolating, and assuming the same growth rate, this means that it will take more than two years before "all" servers are patched, which in my opinion is much too long to leave a security vulnerability such as this unpatched.

At the same time, we have been observing a pattern that I think is of some long term concern: most of the servers that have been patched since early April are not fully TLS compliant. Specifically, these servers do not tolerate a client identifying its highest supported protocol version as 4.1 (a currently non-existent version; SSL 3 and TLS 1.x are using protocol version 3.x).

In the past few weeks, as many as 80-90% of the newly patched servers have refused to negotiate with our tester (the TLS Prober) when it claimed to support the hypothetical v4.1 TLS protocol version (or, as I call it, "TLS NG"). This is much higher than the 69% of all servers that generally exhibit the same problem.

The major TLS protocol version 4 is currently a hypothetical version of the protocol, and there are AFAIK no plans to write a specification that will use this major version number.

So, why worry?

I am concerned. If this version intolerance, which _is_ a violation of the TLS specification, is still in widespread use whenever protocol version 4 is defined, then we will, at best, have an interoperability problem; at worst we could have a serious security vulnerability.

Over the past 10+ years, TLS clients have had to cope with version-intolerant servers because older servers were not written to handle clients supporting newer versions than theirs of the protocol. It usually has been done by silently disabling the newer versions if the server does not tolerate them. This problem persisted well into TLS 1.0 deployment and was also extended to TLS Extension support, which also required clients to implement further fallbacks. This type of problem delayed Opera's activation of TLS 1.1 and TLS extensions for more than a year, after a scavenger hunt revealed the size of the problem, because we had to develop a way to handle the intolerant servers^1,2.

These fallbacks are not just adding serious complications to our code (and every browser's code). They have the added potential to create security problems down the road, if (or more likely, when) a security problem develops in an older version of SSL or TLS that allows an attacker access to the protected data.

Therefore, it was very good that the TLS Renego RFC specifically reiterated the requirement that always existed about version and extension tolerance. Opera followed up on that by requiring Renego patched servers to tolerate a TLS 1.2 (version protocol 3.3) handshake, as mentioned in our article when we started testing.

So far, all servers in our list that have been updated with the Renego patch have implemented this properly with respect to SSL v3 and TLS 1.x tolerance. Very good!

However, it looks like some vendors unfortunately did not thoroughly think through what the version tolerance requirement in the TLS specifications really means. It does not mean, and has never meant, "We can refuse to negotiate with clients offering protocol version 4.0 or larger". It means "That client says it supports version 4.0 or higher, but we only support version 3.x, so we will only talk version 3.x with it".

In some cases, it seems that downstream vendors release updates that only include the Renego patch but did not pick the update that fixed the version intolerance problem. It might be that they did not think it was a security patch.

If these servers are still active when TLS NG (or whatever the next major version of SSL/TLS will be called) is defined and gets implemented, clients will either have to break these sites by refusing to connect to them, or we have to reintroduce the protocol fallback. As mentioned above, the fallback could create a security vulnerability.

Further, if a new major version of TLS is ever created, while there may be other reasons, it will most likely be for either one, or both, of the following two reasons:

• There are new improved protocol techniques that are very incompatible with those currently used in TLS
• The old system's cryptographic protection methods being discovered to have serious vulnerabilities, requiring a complete rewrite of the protocol

In the latter case, assuming the known problems are not so serious that support for older versions must be discontinued immediately, allowing an automatic fallback to be used would allow an attacker to trick a new client to talk to a new server using an old and _vulnerable_ protocol. Oops!

Therefore, since all servers are now being upgraded to protect against the Renego issue, we need to nip the v4-intolerance problem in the bud while it is still relatively small.

So far, we have been able to identify one vendor and have started to contact them about the issue. However, there is not yet a clear pattern to the server version information, which makes it very difficult to determine what other vendors are involved. It is also possible (probably very likely) that, based on the observed variation in server agent, the actual TLS servers in many cases are
SSL/TLS front-end accelerators or firewalls that do not directly inform the client about their involvement in the connection.

We will continue to attempt to identify vendors and contact them about this issue. We also have several other items being developed in relation to this, such as an online test utility.

Currently the *original* SSL/TLS implementations we know have been implemented with correct version tolerance are (some have not been release yet):

• OpenSSL 0.9.8m (for cherry pickers, you can find the relevant patch here)
• OpenSSL 1.0.0
• NSS 3.12.6
• Windows 7 (update not yet released, AFAIK, probably also applies to other windows versions)
• RSA BSafe (version unknown, not sure if it has been released)

There may be other implementations which have not been included.

One thing we have discovered is that some customized variants of OpenSSL with the Renego patch do not include the above mentioned version tolerance patch. The maintainers of such derived distributions should include that patch in their codebase.

For other vendors who wonder whether they need to do anything to their Renego patched system, I may be able to help them if they contact me and provide a URL to a test server that I can test.