First of all, I think it's perfectly reasonable to not get an A if your security is not perfect. Thus, BEAST does not carry "so much weight". For a lot of weight, look at SSL 2 or insecure renegotiation -- if you have those enabled you get an F.
I know that everyone assumes the BEAST had been addressed, but that's not actually the case. Safari continues to be vulnerable. BEAST is actually still exploitable (against Safari), because the Java Same-Origin Policy bypass that was used originally still remains (in a slightly different form; they appear to have failed to fix it).
But you won't hear about this, because people have moved on to the next exciting thing and no one bothers to check.
There is one positive change and that is that the Java plug-in does not appear to have access to httpOnly cookies, making BEAST less interesting. Still, other cookies, HTTP Basic Authentication, and URL-based sessions remain vulnerable.
Some might say that supporting TLS 1.1+ deals with the problem. It might, but it might not, because most browsers are susceptible to protocol downgrade attacks. An active MITM might be able to force TLS 1.0 and then exploit BEAST. I have so far determined that all browsers downgrade connections in case of failure. I am soon to test if they have some sort of rollback defense.
I am well aware that RC4 is not a good cipher, and it pains me to continue to indirectly encourage people to use it. I am sorry I cannot move at a faster pace, but researching these things takes considerable effort, and thus time.
It's actually pretty likely that next week, after I finish with some further tests, SSL Labs will stop penalizing for the BEAST vulnerability.
First off, let me say thanks for an awesome tool. Just because I disagree with the preference of RC4 over AES-CBC doesn't mean I don't think SSL Labs is incredibly useful (I use it all the time to test TLS configs).
In my opinion, if being vulnerable to BEAST means you aren't 'perfect' and capped at a B, then allowing RC4 should have the same effect, as there are very real attacks against TLS's implementation of RC4 as well.
I look forward to the day when we can shut off TLS 1.0 altogether... We disabled SSLv3 a month ago (once it dropped below 1% of our traffic). Alas, TLS 1.0 is still almost 2/3rds of our traffic. The good news is, with the release of Chrome 29 Stable, we've seen a _huge_ spike in TLS 1.2 traffic.
I know that everyone assumes the BEAST had been addressed, but that's not actually the case. Safari continues to be vulnerable. BEAST is actually still exploitable (against Safari), because the Java Same-Origin Policy bypass that was used originally still remains (in a slightly different form; they appear to have failed to fix it).
But you won't hear about this, because people have moved on to the next exciting thing and no one bothers to check.
There is one positive change and that is that the Java plug-in does not appear to have access to httpOnly cookies, making BEAST less interesting. Still, other cookies, HTTP Basic Authentication, and URL-based sessions remain vulnerable.
Some might say that supporting TLS 1.1+ deals with the problem. It might, but it might not, because most browsers are susceptible to protocol downgrade attacks. An active MITM might be able to force TLS 1.0 and then exploit BEAST. I have so far determined that all browsers downgrade connections in case of failure. I am soon to test if they have some sort of rollback defense.
I am well aware that RC4 is not a good cipher, and it pains me to continue to indirectly encourage people to use it. I am sorry I cannot move at a faster pace, but researching these things takes considerable effort, and thus time.
It's actually pretty likely that next week, after I finish with some further tests, SSL Labs will stop penalizing for the BEAST vulnerability.
[Note: I am the guy behind SSL Labs.]