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.htmlltm_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).

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.