Juliano and Thai presented a Proof of Concept of an attack against TLS 1.0 is first documented in 2001 and discussed in papers in 2005 and 2006. It was thought to be an impractical attack back then and solved by adding empty fragments into the IV.

This issue was addressed in TLS 1.1 (2005-6) and OpenSSL by inserting Empty Fragments into the message.

Secondly the OpenSSL option "SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS" is activated by default as it caused incompatibilities with certain SSL stacks. Activating here means removing the mitigation against this attack. It is known thatTomcat, Apache mod_ssl, and Exim disable this feature in OpenSSL by default. Note : The proposed NSS patch (see countermeasures) adds empty application data records, which appears to be more compatible.

To quote Nelson Bolyard on why TLS 1.1 was not introduced sooner in the NSS stack (Currently used by Chrome, Firefox and various servers) :

"There is no significant market demand for TLS 1.1, so we've been working on improvements
in other areas,such as sharable DBs and full RFC 3280 compliance. Once TLS 1.2 finally
becomes an RFC, we will work on that some time thereafter. We believe there will be a
demand for TLS 1.2 and some of the new cipher suites that require TLS 1.2 as a prerequisite."
Source

Mid-Term : Enable and Offer TLS1.1 or TLS1.2 (Note: Firefox and chrome do not support TLS 1.1 and will fallback). For a compatibility overview look here

In the works :

The publication by Juliano and Thai should create the necessary incentive for Vendors to implement and use TLS1.1 and/or TLS 1.2. I will keep an eye on the usual suspects and collect all relevant support in the "TLS/SSL compatibility Report"

The Phone Factor (the guys behind the TLS session renegotiation vulnerability) propose prioritizing RC4 over AES or DES as a short term mitigation.