Cisco provide some solutions related to this attack on blog. Protocols TLS 1.1 and 1.2 do not have a similar vulnerability, Additionally, TLS versions 1.1 (RFC 4346) and 1.2 (RFC 5246) are not affected by this issue. In TLS version 1.1 the implicit Initialization Vector (IV) was replaced with an explicit IV. Also, Datagram Transport Layer Security (DTLS) protocol versions 1.0 and 1.2 are not affected (DTLS is defined in RFC 4347). But these versions of the protocols are not supported any sites or some other popular browsers, and therefore the most popular sites currently are vulnerable. Almost all Web servers at the moment use SSL 3.0 or TLS 1.0. Of all the browsers support TLS 1.2 are only Opera, beginning with the tenth version, and Internet Explorer 8 on Windows 7 and above. Neither Mozilla Firefox, or Google Chrome TLS 1.1/1.2 is not currently supported.
Another thing to highlight is that OpenSSL implemented a feature where they send an “empty TLS record” immediately before they send a message. This empty TLS record causes a change in the CBC state where people consider it to give the message “a new IV” that the attacker can’t predict. This feature in OpenSSL is disabled with the “SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS” option and it’s also included in the “SSL_OP_ALL” option. In OpenSSL versions 0.9.6d and later, the protocol-level mitigation is enabled by default, thus making it not vulnerable to the BEAST attack.For applications that use OpenSSL, this “empty-record” trick can be enabled as a workaround. For a more permanent solution, the adoption of TLS 1.1/1.2 is what’s needed.
Nickm from the Tor Project does a good job introducing the basics on his blog for people who don’t know all the technical details about the TLS protocols and CBC.
