I just noticed that a new v1.0.87 has been deployed and displays a "BEAST attack: vulnerable".
Based on what criteria are you concluding that a server is indeed vulnerable: does a lacking RC4 preferred cipher automatically mean that you consider a server prone to a BEAST attack?
On a test server, I don't include RC4 (whether preferred or optional), but instead opted to activate empty fragments for TLS 1.0 and switched to OpenSSL 1.0.1-stable to get TLS 1.1.
As far as I tested, only IE6 on Windows XP can't handle empty fragments. All other IE versions, whether on XP or 7 are able to connect just fine. Same for recent versions of Firefox, Chrome and Opera.
Yes, you're right: in 1.0.87 I considered a server to be vulnerable if RC4 is not prioritized. However, as you point out, that's inaccurate. Short term, I will remove the warning for those servers that do not use RC4 as a mitigation technique, and only display "Not vulnerable" for those that do. Long term, I will improve the detection. Thank you for bringing this to my attention.
If it's not a problem, please send me your server details so that I can test the improved detection with it.
Since one of the latest versions, BEAST vulnerability detection has changed. Just out of curiousity: based on what criteria are you deciding whether a host is "unknown" or "vulnerable" to the attack?
With the following protocols:
TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes
one is unknown (dev.slimtrader.com, nginx):
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
while another is vulnerable (smtguru.com, IIS 7.5):
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128 TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) 256
Steve, the BEAST test currently depends on the cipher suite preference test, and the latter is not always possible to carry out. It seems that some web servers chose to mitigate BEAST by forcing RC4 ciphers, even when they are not offered by the connecting client. In practice this works because virtually every browsers supports RC4. When it comes to SSL Labs, however, the forcing of RC4 breaks our cipher suite preference test, and thus the BEAST test.
We're saying "unknown" at the moment, which I thought is better than saying either "Vulnerable" or "Not vulnerable". I will fix the issue as soon as I can schedule some development time for it.
This is now fixed in 1.0.101. However, this is an area where server behaviour changes constantly and will continue as web sites mitigate against BEAST and deploy TLS 1.1 and TLS 1.2. We will continue to monitor the situation and tweak the test accordingly. Thanks for your help.
Thanks, I've checked a legacy server, that is known to be vulnerable and it is reported correctly again. On the other hand, the version is now already 1.0.102 and my own test host is reported as being "vulnerable to BEAST attack", although it shouldn't:
SSL Cipher order, as configured in nginx:
which is reported as:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) TLS_RSA_WITH_RC4_128_SHA (0x5) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
The first 8 ciphers are TLS 1.2 only and the first TLS 1.0 one is RC4, so the configuration looks fine to me.
Indeed, after moving AES256_SHA256 after RC4, the warning doesn't appear anymore. This is really weird, as the SHA256-based ciphers are supposed to be TLSv1.2 only and shouldn't be selected for SSLv3 or TLSv1.
I've changed the cipher configuration as follows to make sure RC4 really comes before any SSLv3/TLSv1 ciphers:
I guess this is a feature of the development release of OpenSSL 1.0.1 (ssl/s3_lib.c):
AES256-SHA256 SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
The ciphers 0x3B to 0x40 are marked as SSL_TLSV1.
In my opinion, yes. You should take the steps to address the BEAST problem, as explained here:
KB2585542 addresses only the client side of the BEAST attack, but there's nothing that can be done on the server side for it with a patch.
It seems that the BEAST detection produces false positives:
The warning looks perfectly correct to me.
A TLS 1.0 client will use AES-256-SHA1, which is a CBC cipher and thus be vulnerable to the BEAST attack. You'd have to provide a "safe" cipher to this user, the only one available happens to be RC4.
The problem is: If I allow RC4 ciphers, I won't be vulnerable but your ciphers rating drops. So I can't "win" this game...
For example, I've now configured the ciphers list/order you mentioned in https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls but the ciphers score dropped from 100 to 90...
While one can argue about the pro's and con's of using RC4, you should really ask yourself what's more important to you or your users:
You could always politely inform the user to "upgrade" their browser security by displaying a warning when someone connects with SSLv3 or TLSv1, like discussed in some other thread and implemented by application servers for SSLv2 (i.e. sending an HTTP-500).
While, in theory, this could give you a score of 100 if Ivan would extend this "refused" detection to all SSL/TLS versions, you'll lock out most users. As far as I know, there's no browser that comes with TLSv1.1 enabled by default:
So, what's your goal? Reaching (as close as possible) a score of 100 or merely providing your users a connection that's "secure enough"? I'm quite happy with 91 (2048 bit certificate) or 94 (4096 bit certificate) and don't prevent anyone from accessing my sites while still providing BEAST countermeasures.
My current goal is to get the max out of the possibilties and then check how to deal with clients. Quite a 'whitelist' approach.
I fully understand, that this is not usable outside a "lab condition" but I prefer this way instead of starting "fully vulnerable" and patching the holes as they get found...
Securitymetrics problem will solve with following SSL configuration.
SSLProtocol -SSLv2 -TLSv1 +SSLv3
One basic thing, Block negotiated ciphersuite negotiated which was mentioned compliance report. Example : AES256-SHA negotiated and listed in Compliance then block !AES256-SHA