If there is one unchanging thing about computing and the Internet, it is … change. That is why well engineered protocols and devices are designed to allow newer, improved versions of the protocol or device to be invented. Such flexibility permits them to interact with both older and newer implementations of the protocol or device, so that not everyone need change to the newest version at the same time.

As an example: The reason you will soon "have" to buy a new, more advanced DVD- player in order to play the new DVDs is because the old DVD players does not recognize the new format and the new discs are using a format and data storage method that cannot be read by the old ones. IOW: while there may be insurmountable technical difficulties causing it, DVD players are not forward compatible, and the new DVD formats are not backward compatible.

Many Internet standards, HTML, HTTP, SSL/TLS are both forward and backward compatible. Or rather: They are supposed to be. Actual performance varies between implementations.

Over the past seven years I have been phasing in several new versions and enhancements to the SSL and TLS protocol. Versions and enhancements that were supposed to work with implementations of the older versions without any problem.

They didn't.

The SSL and TLS specifications (all four of them) specify that a client supporting the newer version can connect to a server that only supports some of the older versions, and how they negotiate the version (client tells the server its highest version, and the server picks the lowest version of what the server supports and what the client supports).

Except for the first version (SSL v2), all SSL and TLS versions are binary compatible, and the negotiation formats are also permitted to change, in particular the two first messages. The specification clearly specifies that those two messages can contain more data than was defined at the time the specification was written. With TLS Extensions, those new data fields were defined.

However, not everyone implemented these features as well as they should.

As mentioned in my Opera Labs article (and also here), some older SSL v3 servers refused to talk to TLS 1.0 clients, or when they would talk they used the wrong information internally, causing a connection failure. History repeated itself when TLS 1.1 was introduced.

Also, TLS 1.0 servers refused to accept TLS Extensions, even though they are supposed to ignore what they do not support.

Additionally, there may be a problem with the backward compatibility requirements. I've either misunderstood that section for most of the past nine years, or it isn't clear enough about what it means. What I discovered was that for some SSL v3 and TLS servers which protocol versions and how they were signaled during the handshake was a bit too important, and in some cases servers used the wrong protocol version field when negotiating.

Frankly, it's starting to look messy.

While it does not affect most servers, the problem is that many of these problems occur on important sites such as online banking sites, which means that unless you can compensate for the problems, you have to wait until the sites fix their servers. An alternative approach is to tell the sites to fix their servers, or the customers won't be able to access them, which is effectively what Microsoft did when they implemented TLS Extensions in Vista, where TLS Extensions cannot be disabled. But they may be big enough to make it stick.

In order to compensate for all of this, and more, Opera's SSL/TLS stack had to get a whole lot of logic that could compensate for all of the problems. This permitted us to enable TLS 1.1 and TLS Extensions.

At the last IETF meeting, IETF-65 in Dallas, I was invited to make a short presentation of my experiences. After the presentation I was asked to write a more extensive report about what I had observed.

The first draft of this report is now available as an Internet Draft

Why is it important to be aware of this?

One answer is that knowing what has gone wrong, we can work to improve the process so that we can avoid the problem in the future. My draft does not try to solve the problems, but does ask if certain changes to the process might help.

Another answer is that the countermeasures that several clients have implemented actually negates security features in parts of the protocol. In particular, the version roll-back protection for the RSA cipher suites is affected by this problem. This feature is supposed to prevent an attack that leverages a (potentially) weaker version of the protocol. It is, however, not possible to tell an incorrectly implemented server from a malicious attack.

A third answer is that work is now getting underway to define TLS 1.2. This version is going to introduce new protocol integrity methods, which are what is used to ensure that the protocol data have not been tampered with, because the old methods are starting to show weaknesses.

If it becomes difficult to introduce a new version of the protocol, in particular one intended to increase security, and the only fallback the clients have is to disable the new protocol version (thus creating a security vulnerability) as a part of their normal operating procedure in order to connect to older servers, then we have a very serious problem on our hands.

The good thing is that we are nowhere close to such a situation. Yet.

The only way to handle it, is to forbid clients to disable version in the manner it is currently done. This would enable clients to negotiate safely, but it might cause important services to fail.

Which means we have a problem no matter which choice we make.