Question

Was reading an article in The Register about BEAST which lead me to the SO post about SslStream, BEAST and TLS 1.1

It seems the best way to mitigate the vulnerability is to prefer a non-CBC cipher suite such as rc4-sha.

Is Heroku currently preferring CBC cipher connections? If so, does this mean customer dynos are currently vulnerable to BEAST?

I found OSWAP guide to Testing for SSL-TLS and did some local tests.

I also found Qualys SSL Labs test results for Heroku

Cipher Suites (SSLv3+ suites in server-preferred order, then SSLv2 suites where used)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 1024 bits (p: 128, g: 1, Ys: 128)  256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 1024 bits (p: 128, g: 1, Ys: 128)  128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)    168
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168
TLS_RSA_WITH_RC4_128_SHA (0x5)  128
TLS_RSA_WITH_RC4_128_MD5 (0x4)  128

Since server-preferred order puts TLS_RSA_WITH_RC4_* at the bottom of the list, I’m concluding that Heroku is currently vulnerable to BEAST.

Would love to hear from someone with more experience in this area.

BEAST attack Vulnerable INSECURE (more info)

Answer 1

The best way to defend against the attack demonstrated by BEAST is adopting (both in clients & servers) TLS 1.1. In its absence, the next best thing would be TLS_RSA_WITH_RC4_128_SHA, in my opinion, even if it’s considered “less secure” than AES. Wikipedia has a decent writeup on the known attacks on RC4. Most of them are biases of the output. To give you an idea of the severity of the attacks see the following quotes from the Wikipedia page:

The best such attack is due to Itsik Mantin and Adi Shamir who showed
that the second output byte of the cipher was biased toward zero with
probability 1/128 (instead of 1/256).

also:

Souradyuti Paul and Bart Preneel of COSIC showed that the first and
the second bytes of the RC4 were also biased. The number of required
samples to detect this bias is 2^25 bytes.

The following bias in RC4 was used to attack WEP:

..over all possible RC4 keys, the statistics for the first few bytes
of output keystream are strongly non-random, leaking information about
the key. If the long-term key and nonce are simply concatenated to
generate the RC4 key, this long-term key can be discovered by
analysing a large number of messages encrypted with this key.

However, SSL/TLS does not use a long-term key with a nonce, but establishes a new key for RC4 by hashing (using either MD5 or SHA1, as you’ve seen in Qualys SSL Labs tests) with every connection (and refreshes the key after some period of time).

You can read some more opinions on this matter in this sci.crypt discussion (if you ignore the trolls).