Strictly-speaking, I don't believe so. There's no way to negotiate the compression method. In the case of the server sending data, the client is able to indicate acceptable compression algorithms (via Accept-type headers) before the server sends the data (with Content-Encoding headers indicating compression). With the client sending data first, there's no way for the server to tell the client what is acceptable.

SSL does have support for compression, but there are no compression methods defined other than NULL.

It's apparently an issue with the client-sent data - that is the data that is analyzed. BEAST has no control over the server-sent data, so whatever the server does, short of closing the connection, has no effect.

Based on what is known about this attack, there are a number of ways it can be thwarted without the need for TLS v1.1/v1.2.

1. Google's solution: by randomly sizing the TLS records, this adds randomness to the known plaintext through more frequent padding.

2. OpenSSL's solution of refreshing the IV by adding an empty TLS record - but some MS products have issues with this.

3. TLS v1 permits up to 255 bytes of padding. Most implementations add the minimum amount (up to 7 for 3/DES and 15 for AES). Using a random amount of padding adds randomness to the known plaintext, in a manner similar to, but different than, Google's solution.

4. Use HTTP/1.0. The suspected attack vector requires a long-term TLS connection that is reused by the browser. HTTP/1.0 allows one request per connection. Each connection will use different key material. This means that BEAST's JavaScript request will have different keys than the user's request. This is easily configurable on the server, and requires no changes to the client (unlike solutions 1-3).

The trade-off is that all these options slow down the connection to some degree.