New web attack on SSL/TLS using BEAST

TLS 1.2 does not exhibit this vulnerability. Are there any plans for BIG-IP SSL profiles to support TLS 1.2?

Thanks,
Mike

Understand that BIG-IP v11 should already support TLS 1.2 - try out "tmm --serverciphers 'DEFAULT'" to see.
It would list out AES128-SHA256 and AES256-SHA256 in the native SSL stack used. The main difference is MAC changed from SHA to SHA256 (and it will give higher entropy for the pseudorandom function).

I suppose the SSL profile would also have supported TLS 1.2 (best to hear out from the expert too :p)

But the point for this vulnerability is that not many web service is using TLS1.2 and providers are not moving to higher security level as they may be losing their client who is still using the older version. See statistic of the TLS used in the link below
http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/page2.html

Overall, best to prevent the exploit from even happening at the first place (stop the js injection into the client browser). But we do need to note that the authors claim to also be able to perform the attack on other applications using TLS (such as VPNs), not just web browsers.

Just some quick thoughts ...

Mitigating the initial attack vector, which is a combination of XSS and CSRF is the best bet. BIG-IP v11 does support TLS1.2. However, I do not think that FireFox, Safari, or Chrome support TLS 1.2 yet. And on Windows, only Vista/7 with IE8+ support TLS 1.2. So, there's a very large portion of the Internet population unable to access any site that moved forward with enforcing TLS1.2-only right now.

Thanks Brian. Also saw that the release note of v11 has stated the support of the TLS1.2

http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote_11_0_0_ltm.html#ltm_rn_1100_new

Also understand that TLS1.2 is not enabled by default for Win2008 R2 and IIS that ships with it. But it should be able to enable through registry setting. Even for Apache 2.0, I do not think it support TLS 1.2 yet.

So in that case, to mitigate the attack, ASM come in to enforce client doing TLS1.2 while it handle TLS1.0 with web server. See diagram below. Of course, we are saying attacks cannot get in btw ASM and web server.

[Client] <---TLS1.2---->[ASM]<---TLS1.0--->[Web Server]

Does this sound feasible?

Sorry I suppose it is LTM instead of ASM.

non-CBC ciphers are not vulnerable, so you can mitigate by updating your SSL profiles to eliminate CBC and use something like RC4-sha (widely supported).

Hi Jason,

Could you please let me know how best to make sure my ssl connections use only the non cbc Ciphers. Would it affect any of my applications that are presently running??

 I am running V10.2

Output of my F5 below. is it ok like this or i need to make sure only non cbc ciphers are allowed?

Thanks and hope to hear from you soon.


# tmm --clientciphers DEFAULT
     ID SUITE                          BITS  PROT  METHOD CIPHER MAC    KEYX
 0:   5 RC4-SHA                         128  SSL3  Native RC4    SHA    RSA
 1:   5 RC4-SHA                         128  TLS1  Native RC4    SHA    RSA
 2:  47 AES128-SHA                      128  SSL3  Native AES    SHA    RSA
 3:  47 AES128-SHA                      128  TLS1  Native AES    SHA    RSA
 4:  47 AES128-SHA                      128  DTLS1  Native AES    SHA    RSA
 5:  53 AES256-SHA                      256  SSL3  Native AES    SHA    RSA
 6:  53 AES256-SHA                      256  TLS1  Native AES    SHA    RSA
 7:  53 AES256-SHA                      256  DTLS1  Native AES    SHA    RSA
 8:  10 DES-CBC3-SHA                    192  SSL3  Native DES    SHA    RSA
 9:  10 DES-CBC3-SHA                    192  TLS1  Native DES    SHA    RSA
10:  10 DES-CBC3-SHA                    192  DTLS1  Native DES    SHA    RSA


# tmm --serverciphers DEFAULT
     ID SUITE                          BITS  PROT  METHOD CIPHER MAC    KEYX
 0:   5 RC4-SHA                         128  SSL3  Native RC4    SHA    RSA
 1:   5 RC4-SHA                         128  TLS1  Native RC4    SHA    RSA
 2:  47 AES128-SHA                      128  SSL3  Native AES    SHA    RSA
 3:  47 AES128-SHA                      128  TLS1  Native AES    SHA    RSA
 4:  47 AES128-SHA                      128  DTLS1  Native AES    SHA    RSA
 5:  53 AES256-SHA                      256  SSL3  Native AES    SHA    RSA
 6:  53 AES256-SHA                      256  TLS1  Native AES    SHA    RSA
 7:  53 AES256-SHA                      256  DTLS1  Native AES    SHA    RSA
 8:  10 DES-CBC3-SHA                    192  SSL3  Native DES    SHA    RSA
 9:  10 DES-CBC3-SHA                    192  TLS1  Native DES    SHA    RSA
10:  10 DES-CBC3-SHA                    192  DTLS1  Native DES    SHA    RSA


Regards
Yomi

Thought this link may help as it can specify which cipher to reject handshake. But in term of client connection, if ther is no common cipher suite the ssl handshake will fail meaning the client will get from bigip a tcp reset. applies to new connections. Suggest you check out v11 to captialise the tls1.2 crypto. Understand v10.2.3 also supports it. http://support.f5.com/kb/en-us/solutions/public/7000/800/sol7815.html

@orinzo

You can manually verify the ciphers that are being accepted by a site by using
openssl s_client -connect bob.com:443 -cipher AES256-SHA <-testing each cipher from openssl ciphers.....
...but who wants to do that when we can script it??
and luckily, someone has built a pretty nice script already:

http://blog.techstacks.com/2009/01/verifying-ssl-ciphers.html

It will run through the openssl ciphers and tell you which ones the server responds to in a handshake.