best practice for ssl ciphers

Hi Skuba,

One of our banking customers decided on using the following based on penetration and browser testing:

 
  tmm --clientciphers 'HIGH:!SSLv2:!ADH' 
      ID SUITE                          BITS  PROT  METHOD CIPHER MAC    KEYX 
  0:  53 AES256-SHA                      256  SSL3  Native AES    SHA    RSA 
  1:  53 AES256-SHA                      256  TLS1  Native AES    SHA    RSA 
  2:  55 DH-RSA-AES256-SHA               256  SSL3  Compat AES    SHA    DH/RSA 
  3:  55 DH-RSA-AES256-SHA               256  TLS1  Compat AES    SHA    DH/RSA 
  4:  57 DHE-RSA-AES256-SHA              256  SSL3  Compat AES    SHA    EDH/RSA 
  5:  57 DHE-RSA-AES256-SHA              256  TLS1  Compat AES    SHA    EDH/RSA 
 

Any client that doesn't support one of these ciphers would get a TCP reset. In practice, I don't think the customer has received any complaints from clients who are unable to access the VIPs.

Another option is to use an iRule to enforce high ciphers but give clients who don't support a high enough cipher an HTTP response indicating why they can't access the site. You can do this following a codeshare example:

http://devcentral.f5.com/wiki/default.aspx/iRules/RedirectOnWeakEncryption.html

Aaron

One thing to note: explicitly setting ciphers can affect the BigIP's ability to offload to hardware, which means you could potentially take a CPU hit. Here are some solutions for you to reference. It also may be worth confirming with support on this for the most recent info.

 

 

Cipher Overviews (basically a bunch of links to other solutions of value for SSL):

 

https://support.f5.com/kb/en-us/solutions/public/8000/800/sol8802.html

 

 

Fully accelerated Ciphers:

 

https://support.f5.com/kb/en-us/solutions/public/5000/700/sol5791.html

 

 

-Matt

Agreed... good point. The handshake for ciphers listed as native in the tmm --clientciphers command will be accelerated in hardware and be more efficient.

 

 

Aaron

thanks for all the information, but i'm still a little confused as to how this change will actually effect our users. for example, if i disable EXP-DES-CBC-SHA what web browser will this actually impact? etc

 

 

cheers

If you disable a cipher in the client SSL profile, LTM won't offer it in the list of available ciphers in the server hello during the SSL handshake. There wouldn't be any negative impact if the client and LTM can agree on a cipher. The only problem arises if there isn't at least one cipher in the list of ciphers the client and LTM both support. In that case, the SSL handshake will fail.

 

 

So it's good to configure the limited ciphers on a test VIP and test with each OS/browser combination (or as many as you can) that your web app supports.

 

 

Aaron

The only problem arises if there isn't at least one cipher in the list of ciphers the client and LTM both support. In that case, the SSL handshake will fail.

 

 

So it's good to configure the limited ciphers on a test VIP and test with each OS/browser combination (or as many as you can) that your web app supports.

 

 

Aaron

 

 

 

Hi Aaron

 

 

Thanks again for your response. You've hit the nail on the head there - I've been asked to disable the ciphers mentioned previously ASAP, and I don't know what it will effect (i.e. what combinations of OS/browsers)

 

 

I know this sounds lazy, but I would have thought someone would have produced a list online (not on DevCentral, but I was hoping someone would have a link to a site that says "Cipher A works fine with Windows XP/IE6" etc)

 

 

But I guess not as someone would have posted the link. Looks like it's going to take a while to test this out fully

 

 

Thanks for your help

With the 2011-09-23 news of the following:

 

"BEAST attacks algorithms that use a mode known as cipher block chaining (CBC), in which information from a previously encrypted block of data is used to encode the next block. AES and DES, two strong cryptographic algorithms used to secure network and Web traffic, both use CBC. The RC4 cipher does not."

 

there is concern that we need to re-order our preferred cipher list and possibly eliminate certain ciphers from our list of supported ciphers.

 

 

I've read the below links and wondered if anyone knows of any "F5 responses" to the latest threats ... like "here is how to handle this if you are worried about it".

 

 

 

 

Researchers Claim Attack Tool Can Crack Encrypted Web Traffic

 

http://www.eweek.com/c/a/Security/Researchers-Claim-Attack-Tool-Can-Crack-Encrypted-Web-Traffic-222593/?kc=rss

 

 

New Attack Breaks Confidentiality Model of SSL, Allows Theft of Encrypted Cookies

 

http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091611

 

 

sol8802: Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles

 

http://support.f5.com/kb/en-us/solutions/public/8000/800/sol8802.html

 

 

sol11444: SSL ciphers supported on BIG-IP platforms in version 10.x

 

http://support.f5.com/kb/en-us/solutions/public/11000/400/sol11444.html

 

 

sol10262: SSL ciphers used in the default SSL profiles in BIG-IP version 10.x

 

http://support.f5.com/kb/en-us/solutions/public/10000/200/sol10262.html

 

 

sol6739: SSL ciphers that are fully hardware accelerated on BIG-IP platforms

 

http://support.f5.com/kb/en-us/solutions/public/6000/700/sol6739.html

 

 

sol7815: Configuring the cipher strength for SSL profiles

 

http://support.f5.com/kb/en-us/solutions/public/7000/800/sol7815.html

 

 

sol11631: SSL ciphers used in the clientssl-insecure-compatible and serverssl-insecure-compatible SSL profiles

 

http://support.f5.com/kb/en-us/solutions/public/11000/600/sol11631.html?sr=16754854

 

 

SSL Profiles Part 4: Cipher Suites

 

http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1086418/SSL-Profiles-Part-4-Cipher-Suites.aspx

 

 

Best practice for ssl ciphers

 

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/52/aft/1168042/showtab/groupforums/Default.aspx