Mitigating the BEAST attack on TLS
Last updated on: December 21, 2022
Update (19 March 2013): This blog post advises to use RC4 to migitate the BEAST attack, but RC4 has recently been discovered to be weaker than previously known. At this point the attacks against RC4 are still not practical. The only fully safe choice at the moment is the AES-GCM suites supported only in TLS 1.2. You can find out more in this new blog post.
During the summer rumours about a new attack against SSL started circulating. Then Opera released a patch, but made no comment about what it was patching. Eventually enough information leaked out that some smart people figured what the attack was about. What remained unknown was the exact technique used in the proof of concept, and that was eventually explained in Thai’s blog post. For a comprehensive overview of related links, go to Thierry Zoller’s blog post on BEAST.
As it turns out, the attack itself was conceived years ago, deemed impractical, but it was nevertheless fixed in TLS 1.1. The new attack technique introduced a few optimizations to make it practical.
In terms of mitigation, I expect this problem will be largely addressed on the client side, despite a potential compatibility problem that may cause some TLS sites to stop working. The only reliable way to defend against BEAST is to prioritise RC4 cipher suites, as proposed by PhoneFactor.
Just as an example, here’s one way to do the above in Apache:
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
Not everyone likes RC4, even though there is little to no evidence that it is insecure in the context of SSL/TLS. If your server supports TLS 1.1+ you can try the approach recommended by Steve Caligo:
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
The idea is that you put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients, which are not vulnerable, followed by RC4 for TLS 1.0 clients.
Now that I’ve discussed what works as mitigation, let’s look at a few approaches that do not work:
- Supporting TLS 1.1+ server-side is a good start, but does not amount to much because very few clients support newer versions of the protocol at this time. And even with TLS 1.1+ support client-side, there’s nothing preventing the MITM to force a protocol downgrade back to TLS 1.0. (For a discussion on defense techniques against downgrade attacks, see this thread on the TLS WG mailing list).
- Enabling the empty fragment technique server-side (details for OpenSSL here) does not work either. TLS 1.0 uses two initialisation vectors (IVs), one each for client- and server-side of the communication channel. The vulnerability exploited by BEAST is on the client-side and cannot be addressed by making server-side changes to how data is sent.
- Compression is said to make the attack impossible, but, as with TLS 1.1+, the support for it client-side is inconsistent.
Update (20 Jan 2012): In testing OpenSSL 1.0.1-beta2, which came out yesterday, I realised that it will happily negotiate AES-CBC-SHA256 even on a TLSv1.0 connection. So I removed it from the recommendation, replacing it with two other TLSv1.2 cipher suites.
How to resolve if TLS cannot be upgraded, redhat 5 and 6 does not support newer version of TLS.
I haven’t tested it, but the same string should work even if newer TLS versions are not supported.
I am running Apache 2.4, with openssl 1.0.0-20 (RHEL 6.2),
In the past I’ve never tried to specify a specific cipher order. The following suggested above, which uses TLS 1.2 by preference sounded good to me:
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
Am I correct in thinking though that these TLS 1.2 ciphers are not supported by my openssl version (the output of openssl ciphers -v is below).
Any help / advice would be much appreciated.
Thanks,
Paul
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1
KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1
KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5
EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1
EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1
DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1
KRB5-DES-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(56) Mac=SHA1
KRB5-DES-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(56) Mac=MD5
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export
EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-KRB5-RC2-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC2(40) Mac=SHA1 export
EXP-KRB5-DES-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(40) Mac=SHA1 export
EXP-KRB5-RC2-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC2(40) Mac=MD5 export
EXP-KRB5-DES-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(40) Mac=MD5 export
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
EXP-KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(40) Mac=SHA1 export
EXP-KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(40) Mac=MD5 export
Paul, your version of OpenSSL does not support TLS 1.1 and better. The first version to support these newer protocols is OpenSSL 1.0.1.
Hi Ivan,
I´ve tried to mitigate beast attack in my apache 2.2.1 with the following lines:
SSLHonorCipherOrder on
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!SSLv2:!EXPORT56:!EXPORT40:RC4+RSA:+HIGH:+MEDIUM:+SSLv3:+EXP
But the SSL Server Test scan still show my web server with beast attack vulnerability . My apache does not support TLS 1.1 and 1.2. There is another config that I have to make in httpd.ssl?
Thanks
Rodrigo
Rodrigo,
I believe that the above advice will work, even on a server that does not support newer TLS version. In the case that it does not, here’s what is what we’re using on ssllabs.com:
https://community.qualys.com/thread/9652?tstart=30
SecurityMetrics has rejected all of our Apache tweaks to mitigate the BEAST attack. They did not like the following Cipher settings:
—
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite RC4:HIGH:!MD5:!aNULL:!EDH
SSLHonorCipherOrder on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
SSLHonorCipherOrder on
—
The only one I think that will work is:
SSLCipherSuite RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!ADH:!AESGCM:!AES
Fruther, they said if any of these methods are available at all (regardless of HonorCipherOrder), it will fail:
—
Available SSL3 ciphers:
AES256-SHA
256 bit
DES-CBC3-SHA
168 bit
AES128-SHA
128 bit
Available TLS1 ciphers:
AES256-SHA
256 bit
DES-CBC3-SHA
168 bit
AES128-SHA
128 bit
—
Thanks for any clarity you can provide so we can pass these PCI scans. I’ll reserve my opinion of what I think of these scans for another day.
Without knowing the reasons for the rejection, I cannot comment on their decision. If the complaint is that those settings ultimately allow CBC cipher suites for clients that do not support RC4, then that can be debated.
The SSL Labs test will consider BEAST to be mitigated if the server prefers RC4 to other cipher suites. In practice, virtually all clients support RC4, so practically the risk is very minimal.
If you want to be strict, you have to enable _only_ RC4 on TLS 1.0 and earlier, and any suite with TLS 1.1 and better. However, as far as I am aware, no SSL stack allows this to be configured. I know some people who have patched the source code of OpenSSL to achieve it, though.
Rob: Please post with any resolution you had to this. I’m struggling through the SM (S&M) scan right now.
Hi,
We are looking to pass this test a site that is using SQUID for proxying with SSL without much luck (we can mitigate the issue on our Apache solutions). The server in question is not supporting TLS1.1+ so we have tried the suggestions above (using the Squid equivalent):
https_port 443 defaultsite=XXXXXX cert=XXX options=NO_SSLv2,SING
LE_DH_USE accel vhost cipher=RC4-SHA:HIGH:!ADH
sslproxy_options NO_SSLv2
sslproxy_cipher RC4-SHA:HIGH:!ADH
The only command we cannot appear to replicate in Squid is the 'SSLHonorCipherOrder On' command. Would this be causing the issue?
Thanks
Tony
Tony,
Yes, having the server (Squid, in your case) control cipher suite order is critical. I don’t have any direction experience with Squid and don’t know if it can do that. If you really need to pass the test (e.g., for compliance, etc), you can do that by enabling just the RC4-SHA cipher suite.
You might be causing issues if you go to just RC4 and can’t enable TLS 1.1/1.2. Check out Akamai’s blog on BEAST: https://blogs.akamai.com/2012/05/what-you-need-to-know-about-beast.html
"Unfortunately, not all organizations can use RC4, eliminating one relatively easy fix. For example, FIPS-140-2 is the US Government standard for certification of cryptographic modules and only allows 3DES, AES-128, and AES-256 (along with SHA-1 and SHA-2). If you use the certified OpenSSL FIPS-140 module, it doesn’t even include RC4 as an available cipher. FIPS-140-2 applies to all US Government configurations, HIPAA (via guidelines and standards from the Department of Health and Human Services Office of Civil Rights), and most Financial Services Institutions through their security policies. Inside the US Government, this applies to both web servers and browsers, so there is a corner-case where a web server that only supports TLS v1.0 with RC4 will fail to negotiate with a Government user that only supports v1.0 and FIPS ciphers."
We enabled TLS 1.1 and TLS 1.2 in IE 9 and it broke https://direct.transunion.com – extremely slow page loads, like 30+ minutes. SSL Labs won’t test their site any more for some reason but when we first checked it, and it showed they did’nt have any TLS capabilities at all. I’m not sure if that is what did it or not but we had to disable TLS 1.1 and 1.2 to get the site to work. Or rather, the Windows admins disabled them both. I don’t know if they needed to disable both.
There may be a problem with Apache 2.4.3 and OpenSSL 1.0.1c-fips. If httpd.conf contains "SSLFIPS on", RC4 ciphers are no longer available, which means your httpd may be vulnarable to BEAST, if fips mode is enabled in tls 1.0/sslv3. SSLFIPS off resolves that problem.
@cfelsing As Far as I am aware, the only way to mitigate BEAST _and_ remain FIPS compliant, is to support only TLS 1.1 and better. Of course, then you have the problem of not being compatible with many users' browsers.
I’m curious why the second recommendation here (and plenty of other recommendations I’ve found, too) disables EDH ciphers.
Also, is this safe and reasonable? The SSL test says it’s not vulnerable to BEAST. The +SSLv3 at the end is a more general approach that I think accomplishes the goal of putting the TLS1.1+ ciphers at the beginning of the list.
!aNULL:!DH:!MD5:RC4:!LOW:!EXP:HIGH:+SSLv3
Richard, I think people disable EDH suites because they are slower, and for many forward secrecy is not an important feature. I think the consensus right now is to move to ECDH suites as soon as possible, if you do care about forward secrecy.
Yes, I quite like the +SSLv3 approach. It was brought up on another thread here.
Is SMTP and POP3s/IMAPS vulnerable to BEAST attacks? PCI scanners seem to flag all mail ports for BEAST issues, which is a problem with SMTP with TLS, as severely restricting ciphers causes all kinds of mail issues with other mail servers.
If SMTP is not vulnerable, is there any "official" documentation we can send to these scanning companies to show this to be the case?
BEAST works only when the attacker is able to tightly control plain-text content sent to the victim server, while observing the encrypted stream. To date, no one has proposed (let alone accomplished) a way to exploit SMTP, POP, IMAP, and similar non-interactive protocols.
I am not aware of an "official" page, but I will make a note to write something on our blog about it.
I was wondering why BEAST status becomes "vulnerable" when I try to delete some algorhythm.
Before I find BEAST attack article, I was using this(this is one line, I just split it for reading);
SSLCipherSuite ALL:!SSLv2:!EXP:!MEDIUM:!LOW:+HIGH:!MD5:!DES:!3DES:
!CAMELLIA128:!AES128:!ADH:!EDH:!aNULL:!eNULL:!COMPLEMENTOFALL
>> Result: BAD / Just some ciphers
And here is an image:http://postimage.org/image/jsre3rrhj/
So I use this;
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
>> Result: OK / Many ciphers
Source: http://www.apachelounge.com/viewtopic.php?t=4337
I want to know *what cipher suits* triggers BEAST attack.
P.S. I use SSL check tool, because your webservice *will* expose my server’s vuln to others.
@qe555z,
Any CBC suite when used with SSL 3.0 or TLS 1.0 is vulnerable to BEAST. The mitigation I believe to be sufficient is to give RC4 preference, in which case you can keep your CBC suites for those rare cases when you encounter a client that does not support RC4. Thus, mitigation is not necessarily about what suites you have enabled, but in which order they are used. Practice with "openssl ciphers" until you achieve the correct order.
@Petri
Thanks for your tips. Just a note to say that some QSA are quite strict and do not allow any CBC suites with vulnerable protocols, even if RC4 is given priority.
Simple PCI DSS compliant and compatible setup for RHEL5 Apache with 3DES as last resort against BEAST:
SSLHonorCipherOrder OnSSLProtocol All -SSLv2SSLCipherSuite RC4-SHA:AES256-SHA:AES128-SHA:DES-CBC3-SHASimple CRIME reduction for same setup:
echo >>/etc/sysconfig/httpd export OPENSSL_NO_DEFAULT_ZLIB=1Has anyone had success with PCI compliance on SBS 2008 servers? I’ve looked into the FitIt options but none of those appear to work on the SBS server line – even though at the root of the server the Operation System is either Windows Server 2008 or Windows Server 2008 R2.
Currently failing PCI compliance based on the BEAST vulnerability (7 instances based on different services/ports). Oddly enough the Qualys scan fails for another reason which as been fixed but their PCI vendor utilizes TrustWave which is failing on the 7 different instances.
Well, I did disable all cipher and only allow 256bit ciphers but still got beast attack error :-( I have to keep TLSv1 because most of my users use Firefox and FF didn’t use TLSv1.1 and TLSv1.2.
You didn’t understand the problem.
You can enable 256 bits cipher suites, but ONLY the ones that use SHA256 or SHA384 hashing!
If you really need to support TLSv1 you MUST ONLY enable "TLS_ECDH_RSA_WITH_RC4_128_SHA" and "SSL_RSA_WITH_RC4_128_SHA" and not any other cipher suite for SSLv2.0, SSLv3.0, TLSv.1.0 protocols.
Make sure you prioritise ECDH over the none ECDH version in RC4… so it will be more secure for the web client browsers that support it.
Also make sure you prioritise AES ciphers (that use SHA256 and SHA384) before RC4 ones… I suggest the follow list… if you take security serious and not server impact:
TLS v1.2 cipher suites
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDHE-RSA-AES256-SHA384 (ECDHE: P512)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE-RSA-AES256-GCM-SHA384 (ECDHE: P512)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE-RSA-AES128-SHA256 (ECDH: P256)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 (ECDH: P256)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 ECDH-RSA-AES256-SHA384 (ECDHE: P512)
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 ECDH-RSA-AES256-GCM-SHA384 (ECDHE: P512)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 ECDH-RSA-AES128-SHA256 (ECDH: P256)
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 ECDH-RSA-AES128-GCM-SHA256 (ECDH: P256)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE-RSA-AES256-SHA256 (DHE: 4096 bits or at least: 2048)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE-RSA-AES256-GCM-SHA384 (DHE: 4096 bits or at least: 2048)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE-RSA-AES128-SHA256 (DHE: 4096 bits or at least: 2048)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE-RSA-AES128-GCM-SHA256 (DHE: 4096 bits or at least: 2048)
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH-RSA-AES256-SHA256 (DH: 4096 bits or at least: 2048)
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 DH-RSA-AES256-GCM-SHA384 (DH: 4096 bits or at least: 2048)
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH-RSA-AES128-SHA256 (DH: 4096 bits or at least: 2048)
TLS_DH_RSA_WITH_AES_128_GCM_SHA256 DH-RSA-AES128-GCM-SHA256 (DH: 4096 bits or at least: 2048)
TLS_RSA_WITH_AES_256_CBC_SHA256 AES256-SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384 AES256-GCM-SHA384
TLS_RSA_WITH_AES_128_CBC_SHA256 AES128-SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256 AES128-GCM-SHA256
TLS v1.1 and TLS v1.0 cipher suites
TLS_ECDH_RSA_WITH_RC4_128_SHA ECDH-RSA-RC4-SHA (ECDH: P256)
TLS_RSA_WITH_RC4_128_SHA RC4-SHA
Probably the order to enter should be something like this… depending on your SSL library.
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DH_RSA_WITH_AES_256_CBC_SHA256, TLS_DH_RSA_WITH_AES_256_GCM_SHA384, TLS_DH_RSA_WITH_AES_128_CBC_SHA256, TLS_DH_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_SHA
I give priority to CBC over GCM algorithms, because GCM is a relatively new mode and I’m not sure if it’s realy secure… I know it is more eficient… but only time will tell if it’s really secure.
If server impact is big, you can for example not add the DHE and DH cipher suites, while maintaining ECDHE and ECDH ones. But be aware that the only other browser that supports TLS 1.2 and TLS 1.1 besides Microsoft Internet Explorer, in Windows machines, is Opera… and this one only supports DHE and DH, not ECDHE and ECDH… so different keys for every session of this users is not possible… and if the main key is compromise (thief, court order, private key discovered trough cracking, …) all previous communications are immediately decipher.
You probably want to update this advise. With the recent discovered CVE-2013-2566 vulnerability you shouldn’t be advising RC4 over CBC based ciphers anymore. The BEAST CVE-2011-3389 vulnerability has been patched in all major browsers, so it is a thing from the past.
Please consider updating https://www.ssllabs.com/ssltest/ as well. Test for RC4 and warn servers not to use it anymore.
Actually, the BEAST vulnerability has not yet been patched in all major browsers. As far as I am aware, Apple hasn’t updated their browsers on OSX and iOS. Which means that CBC and RC4 suites are equally undesirable, and that only the GCM suites in TLS 1.2 remain strong. CBC suites in TLS 1.1 and better are OK, assuming the stack has been patched for the timing issues (Lucky 13).
I will update this blog post and the test soon.
Thanks for the reply. Indeed I forgot about Safari in my "major browser" check. Safari on OS X 10.8 and iOS 5+ does support TLS 1.2 though (not on Windows). I agree with recommending the GCM suites in TLS 1.2, but switching off TLS 1.0 is not a real option yet. So for TLS 1.0 I would recommend CBC over RC4 at the moment. This should give the widest browser support with the lowest risks.
You have contradicted yourself and your scan as well as other major scanning companies are falsely showing a positive for BEAST vulnerability. Above you state
"As it turns out, the attack itself was conceived years ago, deemed impractical, but it was nevertheless fixed in TLS 1.1."
Then you say
"The only reliable way to defend against BEAST is to prioritise RC4 cipher suites"
Unfortunately there are a lot of scanning scripts that follow the latter statement and ignore the first. For instance, if a site have TLS 1.0 and 1.1 disabled and does not have RC4 the SSL Labs Server test will show
This server does not mitigate the BEAST attack. Grade capped to B.
The sites are not vulnerable to BEAST since TLS1.0 is disabled.
I have been researching SSL security and would like to get your opiniion on the following statement made on another security related web site, calomel dot org:
'You may have noticed we only use the strongest AES ciphers and do not allow RC4.
Is calomel.org vulnerable to the ssl BEAST attack or ssl compression CRIME attack ?
No, we use OpenSSL’s "empty fragment" feature which inserts a single empty TLS record before every record sent.
This empty record effectively randomizes the initialization vector (IV) of the following records similar to TLS 1.1.
We also do not use SSL compression on standard or SPDY connections.
The result is these attacks are essentially neutralized for TLSv1 clients like Firefox, Chrome and Safari when they connect to us.'
Does your SSL test check for the OpenSSL "empty fragment" feature and if so how would those results be read?
Since I primarily use Firefox and many banking web sites do not support secure renegotiation what can Firefox users do or what should we look for when using such web sites? If an attacker were to attempt to intercept the connection what might it look like to an end user and what should the end user do?
I have used the Opera browser in the past but I have found it sometimes loses or appears to lose a secure connection even to TLS 1.2 servers at random. This prompted me to go back to Firefox using several add-ons like calomel, noscript, cert patrol and a few others. I also enabled "security.ssl.require_safe_negotiation" in Firefox but some web sites do not support this. I also prefer to use an open source browser.
And for Firefox, which supports higher strength encryption algorithms, which do you believe is more secure, RC4-128 or AES-256 (non-CBC) connections?
Thank you.
secure_the_internet,
1. In response to the claim that server-side empty frament feature addresses BEAST — that’s not correct. BEAST is a client-side vulnerability and can be addressed only by client-side empty fragment or (better) 1/n-1 split.
2. If your browser is accepting connections to sites that do not support secure renegotiation (and I believe that most do), a well-executed attack on you may be very difficult to detect. However, it’s difficult to say how much effort such an attack would require, as that largely depends on the nature of the web site. Seeing unexpected pages (e.g., you requrest one page, but get something entirely different) might be a sign.
3. Any AES connection should be preferred over any RC4 connection, assuming no CBC issues (e.g., using GCM suites or TLS 1.1 or better). In practice, however, I don’t think it matters much.
Was just wondering in what versions of browsers this vulnerability has been mitigated. Your prompt response is greatly appreciated.
As far as I am aware, Chrome, Firefox, IE, and Opera mitigated this problem some time ago. Apple did not (although I think Apple supports TLS 1.1 and 1.2 on iOS).
Thank you Ivan for your prompt response. When running the SSL Test, it comes with the message the server is still vulnerable to beast attack even though we are not running any of the outdated browsers. The TLS 1.1 and 1.2 comes with NO when running the SSL test. Could you please explain on how do we go about mitigating it even though the browser versions that we are running are updated. Thank you so much.
To mitigate, you need to change your configuration as explained in this blog post. As for not using any vulnerable clients — that might be possible in tightly controlled environments, but it’s impossible for a public web site where end-users decide what browsers to use.
After testing many of the web sites I use for banking I am a little concerned at how many do not seem to be configured to properly implement client side support for RFC 5746.
I usually leave the Firefox option of "security.ssl.require_safe_negotiation" set to true.
Details on this option can be found here: https://wiki.mozilla.org/Security:Renegotiation
But many banking institutions and credit agencies have yet to correct this issue. I have attempted to contact a few but they usually send a response that makes it clear they do not understand the issue.
Perhaps it would help to create a blog post with all recommended ecurity settings in one place? At least for the major web servers such as Apache, IIS, IBM, etc.
If a web site does not implement client side support for RFC 5746 what implications, if any, would that have for TLS 1.2 connections? One example of a misconfigured site like this is Amex. You can connect using TLS 1.2 but if you use Firefox you can not connect using the "security.ssl.require_safe_negotiation" option enabled.
How would you and any web site administrators who may be reading this recommend the best way of contacting a web admin about this issue?
Hi,
it looks like ssllabs doesn’t consider all CBC ciphers on TLS1.0 beast vulnerable. Is this a bug or is there some reasoning behind it?
See https://www.ssllabs.com/ssltest/analyze.html?d=lighttpd.net
(Using "AESGCM+ECDH@STRENGTH RC4+ECDH@STRENGTH -AECDH ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA RC4-SHA")
No, all CBC suites are considered vulnerable when used with a vulnerable protocol. The server probably uses one set of suites for TLS 1.1+ and RC4 for earlier protocols.
No, I didn’t add that yet to our openssl module (only the gnutls one has it, and it breaks session resumption and triggered a segfault in one of the latest gnutls releases).
You can see it in the handshake simulation:
Firefox 21 / Fedora 19 TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) FS 256
Also checked with gnutls-cli:
gnutls-cli –priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:-CIPHER-ALL:+AES-256-CBC" lighttpd.net
– Description: (TLS1.0-PKIX)-(ECDHE-RSA-SECP256R1)-(AES-256-CBC)-(SHA1)
– Version: TLS1.0
Our test works slightly differently: accepting a CBC suite is not considered a failure, but accepting a CBC suite when a RC4 suite is available is a failure.
For example, try this:
$ openssl s_client -connect lighttpd.net:443 -tls1 -cipher 'AES256-SHA ECDHE-RSA-RC4-SHA'
Going back to Fedora 19 simulation: our BEAST test is performed using a imagined client that supports certain suites. Fedora 19 does not support the same suites, which is why you don’t have RC4 there. But, Fedora 19 has been patched to mitigate BEAST ;-)
I thought some days over this, but it still doesn’t make sense.
I think the logic implemented in ssllabs right now is: if there is ANY RC4 cipher on the top of the ciphers working with TLS1.0 the server is considered not vulnerable to BEAST.
For example I can put TLS_ECDHE_RSA_WITH_RC4_128_SHA after some TLS1.2 only ciphers, and it doesn’t matter what follows.
I think this is wrong. As you said: accepting a CBC suite is wrong if a RC4 suite could have been selected (while using TLS1.0 and before ofc). So theoretically ALL RC4-ciphers (lets exclude MD5…) must be available and come before any cipher working with TLS1.0 to be safe against BEAST.
I’d say it is safe to assume that all clients support SSL_RSA_WITH_RC4_128_SHA, so it is enough to have SSL_RSA_WITH_RC4_128_SHA above all TLS1.0 ciphers; otherwise for any kex exchange algorithm you support the matching RC4 cipher must be present, assuming that all clients will support RC4 for all key exchange algorithms they support if possible (which is wrong: gnutls doesn’t support ECDH(E)-RC4 yet).
My client example was just about the fact that a client with a certain ciphersuite list could end up with a CBC cipher with TLS1.0 and certainly having RC4 suites in the list; I didn’t mean to imply that Fedora 19 didn’t implement the 1/n-1 split (although I bet not everyone did apply the update…).
I read your response a couple of times but I am still not quite sure what you disagree with.
The logic is currently not about ANY RC4 suites. Here’s a more detailed explanation:
1. First, we inspect a server for all suites it supports.
2. We test for BEAST on SSL 2, SSL 3, and TLS 1.0.
3. For SSL 3 and TLS 1, we take all supported suites, reorder them so that all RC4 suites are at the end, then add a few more RC4 suites to the list*, and then submit a request
4. If we get a RC4 suite in response, we consider the server not vulnerable
(*) This is because some servers will not offer any RC4 suites, _except_ when SSL 3.0 and TLS 1.0 are used. This bit was not initally in the test; it was added only later, in response to the earlier version of test failing.
In the end, it’s very simple: we have an imaginary "SSL Labs" browser that supports a number of RC4 suites (including SSL_RSA_WITH_RC4_128_SHA). If a server negotiates a CBC suites with this browser (using SSL 3 or TLS 1), we consider it vulnerable.
Perhaps a better solution is to more toward assessing what’s used with major clients but, before we can do that, we need to build up the device database. We currently cover desktop browsers pretty well, but need to work on the mobile devices.
There are many clients that only support SSL_RSA_WITH_RC4_128_SHA, and no other RC4 ciphers (ECDHE+RC4). You only test whether clients that support the same RC4 cipher set as your imaginary client are safe on a server, but you should test whether all ("sane") clients are safe.
This means your imaginary client probably should add only SSL_RSA_WITH_RC4_128_SHA (which is supported by all "sane" clients supporting RC4 ciphersuites) and drop the other RC4 ciphersuites.
I know about the version handling, because I reported that problem :-)
Another question is what impact BEAST still has; you said in https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what that apart from Apple all vendors implemented 1/n-1 split. But the recent Apple versions support TLS1.2, so perhaps supporting TLS1.1 could be considered as BEAST mitigation too now.
Another test you could implement for fun: test session resumption with tickets *twice*, because gnutls breaks on the second resumption attempt (if ticket and db is enabled serverside): http://lists.gnutls.org/pipermail/gnutls-devel/2013-August/006413.html
Regarding BEAST impact, in recent months I researched it a lot, exploring all exploitation venues. I now consider it mitigated (changes to SSL Labs will be made in the following weeks). But not because of TLS 1.2, but because the Java plug-in can no longer be exploited in a way that made BEAST possible.
Regarding TLS 1.2, all browsers are vulnerable to practical protocol downgrade attacks. A MITM can downgrade any browser-made connection today down to SSL 3.0.
(Thanks for reporting that problem. Sorry I didn’t "recognize" you. :-))
What do you think about the following Apache2 configuration ?
#
# https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.2.pdf
# http://www.openssl.org/docs/apps/ciphers.html
#
SSLHonorCipherOrder On
SSLCompression Off
SSLInsecureRenegotiation Off
SSLProtocol ALL -SSLv2
SSLCipherSuite TLSv1.2:TLSv1.1:RC4:SSLv3:TLSv1:!SSLv2:!eNULL:!aNULL:!MD5:!EXP:!ADH:!EDH:!DES
The goal is
* Reach Qualys’s SSL Lab Grade A
* Be PCI compliant
* Be invulnerable to BEAST attack
* Compatibility with most of the "current" browsers
* Support new ciphers without having to list them one by one
I did not manage to reach a Grade A by using ALL:…
because I could not change the order to have RC4 in the middle of the list.
openssl ciphers -v 'TLSv1.2:TLSv1.1:RC4:SSLv3:TLSv1:!SSLv2:!eNULL:!aNULL:!MD5:!EXP:!ADH:!EDH:!DES' | cut -d' ' -f1
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES256-SHA384
AES256-GCM-SHA384
AES256-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA256
ECDH-ECDSA-AES128-SHA256
AES128-GCM-SHA256
AES128-SHA256
ECDHE-RSA-RC4-SHA
ECDHE-ECDSA-RC4-SHA
ECDH-RSA-RC4-SHA
ECDH-ECDSA-RC4-SHA
…
Guy,
I recommend that you use the configuration from this blog post:
https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
Ivan,
Thanks for the link but our current Apache version (2.2.22)
on Debian Wheezy unfortunately does not support
Forward Secrecy.
What do you think about my approche to use cipher suites
to change the order and have TLS 1.2, 1.1 first,
RC4 in the middle to mitigate the compatibility issue
and SSLv3 plus TLS 1.0 at the end ?
SSLHonorCipherOrder On
SSLCompression Off
SSLInsecureRenegotiation Off
SSLProtocol ALL -SSLv2
SSLCipherSuite TLSv1.2:TLSv1.1:RC4:SSLv3:TLSv1:!SSLv2:!eNULL:!aNULL:!MD5:!EXP:!ADH:!EDH:!3DES:!DES:!PSK:!SRP:!DSS
Do you know if the above Apache config will include Forward Secrecy by default
after moving to Apache 2.4 ?
Thanks.
Guy
Guy,
I recommend that you test that configuration yourself by using the "openssl ciphers" command.
If you move to Apache 2.4.x and OpenSSl 1.0.1c or better, you will have Forward Secrecy following when following my advice from that other post.
Is this vulnerability mitigated client side, even on servers that are vulnerable to it, like the yahoo mail login?
Yes, you could say that this vulnerability is mitigated client-side by now. That’s assuming you’re using a modern browser, you don’t have Java installed, or, if installed, it’s fully patched.
Hi,
I have my ESXi server and its affected with BEAST attack can anybody help me for this. or can anybody tell me how to disable TLS1.0 on esxi ?
Hi,
How to disable on windows 2008 r2 server for below vulnerability. we need to mitigate this.
SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST)