There is a theory that the TLS Session ID might mitigate the BEAST attack, and one of the comments at the IETF mention that SSL Accelerators may alter this ID.
Can someone explain to me (or tell me where to go) to understand what an SSL Accelerator may to do to the TLS session that is different than a regular session?
An SSL accelerator typically works like this:
Client <-SSL-> Accelerator <-HTTP-> Server
This means the server doesn't have to deal with the overhead of SSL. But it also means the details of the SSL session are invisible to the server. In theory, the accelerator could add a header to the HTTP request that contains an identifier unique to the HTTP session, but I don't know of any accelerators that actually do this.
The notion of an "SSL accelerator" also applies to crypto acceleration cards which support the generation of asymmetric keypairs and / or the symmetric encryption/decryption operations. In this case the acceleration consists purely of algorithmic aid and does not involve protocol specifics (especially no TLS session IDs).
As for the other part of the question, the BEAST attack is surely not prevented by the use of session IDs instead of cookies. Although there can't be cookie theft if the cookie is tied to the session ID, the attack itself is still usable to sniff on other connection data. The only ways to counter the BEAST attack are to either abandon TLS 1.0 and use newer versions of the protocol only - or disable all block ciphers using CBC (a special kind of encoding for block ciphers) for TLS 1.0 - which would mean disabling all block ciphers and leaving RC4 (which is a stream cipher and thus does not require the use of previous encoding) as the only available cipher.
