Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Summary of client-ssl profile keywords

Hi,
there is already a lot of discussions and articles on the subject here on DevCentral. The following post is declared as general discussion and asks for your feedback.
In this post I will list up my notes on building SSL/TLS ciphers for client-ssl profiles.
Another future post may summarize using additional command line tools used for testing.

For setting up new ciphers F5 has provided a command line tool which is simply used as follows:
tmm --clientciphers '<your-cipher-string-here>'

By entering a cipher string you can expect a sorted list as it will be applied in a client-ssl profile using this string. Using the tool does not modify the running or startup configuration of the system.
Changes finally need to be done to a specific client-ssl profile.

For building a cipher you will use keywords. The available definitions do not exactly match the ones that are used with OpenSSL.
F5 has added/removed some aliases/keywords and allows to sort ciphers.

Generally be aware that some ciphers are available in specific protocol versions only.

These are the protocol keywords as used in TMOS:
SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2, DTLSv1

As a cipher consists basically of three components, you will set up combinations of key exchange / authentication methods, bulk encryption and message authentication.

These are the keywords for key exchange / authentication (the asymmetric part during the handshake): RSA, EDH or DHE, ECDH_RSA, ECDHE, ECDH_ECDSA, ECDHE_ECDSA, ADH, DHE_DSS

These are the keywords for bulk encryption (the symmetric part to exchange application data):
AES, AES-GCM, DES, 3DES, RC4, NULL

These are the keywords for message authentication (aka MAC to hash the exchanged application data):
MD5, SHA, SHA256, SHA384 (This is independent from the certficate hash method!)

Several symbols are used in cipher definitions.
By using prefix ! the following cipher or combination of keywords can be prohibited.
By using prefix + the following cipher or combination of keywords will be moved to the end of the list.
Alternatively using + combines keywords i.e. a cipher with a protocol version.
By using prefix - the following cipher or combination will be disabled but might be re-enabled later in a specific combination. (I.e. RC-4 is generally disabled but permitted in combination with SHA1-MAC: '-RC4:RC4+SHA')

Depending on support inside TMOS (including hardware offload) or by fallback to OpenSSL you can choose the following keywords:
NATIVE, COMPAT

Depending on TMOS versions F5 supports different protocol versions, methods for key exchange and authentication, bulk crypto, strength and message authentication. Thats why the following aliases will return different output depending on your TMOS version:
ALL, DEFAULT, LOW, MEDIUM, HIGH, EXP, EXPORT

I have found the following additional keywords to restrict ciphers:
EXPORT56, EXPORT40

Last but not least you can use the following operators to sort your ciphers: @SPEED, @STRENGTH

When building your ciphers you need to consider the capabilities of your TMOS version and certificates you have in use. Do not include ciphers supporting ECDSA or DSS/DSS authentication if you have RSA based certificates only.

As current browsers (i.e. FF42, Chrome47, EDGE25) are supporting and prioritizing ECDSA it might be worth to add ECDSA based keys/certs to your client-ssl profile settings (RSA is still mandatory in TMOS configurations).

You can choose between different strategies. To list just two:

1) Use NATIVE and selectively exclude and prioritize the protocols, handshake/auth, bulk crypto and MAC.

Here is an expample which is based on this approach by preferring SHA2-MAC and ECDH based handshake and prioritizes on protocol version.
DSS/DSA and ECDSA were excluded as you may not have the key/cert/chain available:

tmm --clientciphers 'NATIVE:+SHA:+SHA384:+RSA:+TLSv1_1:+TLSv1:!SSLv3:!SSLv2:!DTLSv1:!EXPORT:!RC4:!MD5:!NULL:!DES:!ADH:!DHE:!DHE_DSS:!ECDHE_ECDSA:!ECDH_ECDSA'
       ID  SUITE                            BITS PROT    METHOD  CIPHER  MAC     KEYX
 0: 49199  ECDHE-RSA-AES128-GCM-SHA256      128  TLS1.2  Native  AES-GCM  SHA256  ECDHE_RSA
 1: 49191  ECDHE-RSA-AES128-SHA256          128  TLS1.2  Native  AES     SHA256  ECDHE_RSA
 2: 49201  ECDH-RSA-AES128-GCM-SHA256       128  TLS1.2  Native  AES-GCM  SHA256  ECDH_RSA
 3: 49193  ECDH-RSA-AES128-SHA256           128  TLS1.2  Native  AES     SHA256  ECDH_RSA
 4: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1.2  Native  AES     SHA     ECDHE_RSA
 5: 49167  ECDH-RSA-AES256-SHA              256  TLS1.2  Native  AES     SHA     ECDH_RSA
 6: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1.2  Native  DES     SHA     ECDHE_RSA
 7: 49165  ECDH-RSA-DES-CBC3-SHA            192  TLS1.2  Native  DES     SHA     ECDH_RSA
 8: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1.2  Native  AES     SHA     ECDHE_RSA
 9: 49166  ECDH-RSA-AES128-SHA              128  TLS1.2  Native  AES     SHA     ECDH_RSA
10: 49200  ECDHE-RSA-AES256-GCM-SHA384      256  TLS1.2  Native  AES-GCM  SHA384  ECDHE_RSA
11: 49192  ECDHE-RSA-AES256-SHA384          256  TLS1.2  Native  AES     SHA384  ECDHE_RSA
12: 49202  ECDH-RSA-AES256-GCM-SHA384       256  TLS1.2  Native  AES-GCM  SHA384  ECDH_RSA
13: 49194  ECDH-RSA-AES256-SHA384           256  TLS1.2  Native  AES     SHA384  ECDH_RSA
14:    61  AES256-SHA256                    256  TLS1.2  Native  AES     SHA256  RSA
15:   156  AES128-GCM-SHA256                128  TLS1.2  Native  AES-GCM  SHA256  RSA
16:    60  AES128-SHA256                    128  TLS1.2  Native  AES     SHA256  RSA
17:    53  AES256-SHA                       256  TLS1.2  Native  AES     SHA     RSA
18:    10  DES-CBC3-SHA                     192  TLS1.2  Native  DES     SHA     RSA
19:    47  AES128-SHA                       128  TLS1.2  Native  AES     SHA     RSA
20:   157  AES256-GCM-SHA384                256  TLS1.2  Native  AES-GCM  SHA384  RSA
21: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1.1  Native  AES     SHA     ECDHE_RSA
22: 49167  ECDH-RSA-AES256-SHA              256  TLS1.1  Native  AES     SHA     ECDH_RSA
23: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1.1  Native  DES     SHA     ECDHE_RSA
24: 49165  ECDH-RSA-DES-CBC3-SHA            192  TLS1.1  Native  DES     SHA     ECDH_RSA
25: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1.1  Native  AES     SHA     ECDHE_RSA
26: 49166  ECDH-RSA-AES128-SHA              128  TLS1.1  Native  AES     SHA     ECDH_RSA
27:    53  AES256-SHA                       256  TLS1.1  Native  AES     SHA     RSA
28:    10  DES-CBC3-SHA                     192  TLS1.1  Native  DES     SHA     RSA
29:    47  AES128-SHA                       128  TLS1.1  Native  AES     SHA     RSA
30: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1    Native  AES     SHA     ECDHE_RSA
31: 49167  ECDH-RSA-AES256-SHA              256  TLS1    Native  AES     SHA     ECDH_RSA
32: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1    Native  DES     SHA     ECDHE_RSA
33: 49165  ECDH-RSA-DES-CBC3-SHA            192  TLS1    Native  DES     SHA     ECDH_RSA
34: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1    Native  AES     SHA     ECDHE_RSA
35: 49166  ECDH-RSA-AES128-SHA              128  TLS1    Native  AES     SHA     ECDH_RSA
36:    53  AES256-SHA                       256  TLS1    Native  AES     SHA     RSA
37:    10  DES-CBC3-SHA                     192  TLS1    Native  DES     SHA     RSA
38:    47  AES128-SHA                       128  TLS1    Native  AES     SHA     RSA

2) Dump ALL ciphers using the tool tmm --clientciphers 'ALL' and pick the ciphers you want in combination (by using the +) with the preferred protocol to build a list.
The order matters.
Btw, list elements are separated by space "" or colon ":". The keywords are not case sensitive.
Especially the second approach requires review with each TMOS update and consideration of known issues regarding cipher string length!

Here is an example which is allowing TLSv1.2 only in combination with AES, AES-GCM and 3-DES combined with RSA authentication (achieved by excluding ECDHE_ECDSA and ECDH_ECDSA):

tmm --clientciphers 'TLSv1_2+AES-GCM:TLSv1_2+AES:TLSv1_2+3DES:+SHA384:!ADH:!DHE:!DHE_DSS:!ECDHE_ECDSA:!ECDH_ECDSA'
       ID  SUITE                            BITS PROT    METHOD  CIPHER  MAC     KEYX
 0: 49199  ECDHE-RSA-AES128-GCM-SHA256      128  TLS1.2  Native  AES-GCM  SHA256  ECDHE_RSA
 1: 49201  ECDH-RSA-AES128-GCM-SHA256       128  TLS1.2  Native  AES-GCM  SHA256  ECDH_RSA
 2:   156  AES128-GCM-SHA256                128  TLS1.2  Native  AES-GCM  SHA256  RSA
 3: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1.2  Native  AES     SHA     ECDHE_RSA
 4: 49167  ECDH-RSA-AES256-SHA              256  TLS1.2  Native  AES     SHA     ECDH_RSA
 5:    61  AES256-SHA256                    256  TLS1.2  Native  AES     SHA256  RSA
 6:    53  AES256-SHA                       256  TLS1.2  Native  AES     SHA     RSA
 7: 49191  ECDHE-RSA-AES128-SHA256          128  TLS1.2  Native  AES     SHA256  ECDHE_RSA
 8: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1.2  Native  AES     SHA     ECDHE_RSA
 9: 49193  ECDH-RSA-AES128-SHA256           128  TLS1.2  Native  AES     SHA256  ECDH_RSA
10: 49166  ECDH-RSA-AES128-SHA              128  TLS1.2  Native  AES     SHA     ECDH_RSA
11:    60  AES128-SHA256                    128  TLS1.2  Native  AES     SHA256  RSA
12:    47  AES128-SHA                       128  TLS1.2  Native  AES     SHA     RSA
13: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1.2  Native  DES     SHA     ECDHE_RSA
14: 49165  ECDH-RSA-DES-CBC3-SHA            192  TLS1.2  Native  DES     SHA     ECDH_RSA
15:    10  DES-CBC3-SHA                     192  TLS1.2  Native  DES     SHA     RSA
16: 49200  ECDHE-RSA-AES256-GCM-SHA384      256  TLS1.2  Native  AES-GCM  SHA384  ECDHE_RSA
17: 49202  ECDH-RSA-AES256-GCM-SHA384       256  TLS1.2  Native  AES-GCM  SHA384  ECDH_RSA
18:   157  AES256-GCM-SHA384                256  TLS1.2  Native  AES-GCM  SHA384  RSA
19: 49192  ECDHE-RSA-AES256-SHA384          256  TLS1.2  Native  AES     SHA384  ECDHE_RSA
20: 49194  ECDH-RSA-AES256-SHA384           256  TLS1.2  Native  AES     SHA384  ECDH_RSA

Another example demonstrates the ordered combination of protocol with handshake/auth and bulk crypto and preferring SHA2 and SHA.
In this example both RSA and ECDSA certs/keys/chains can be used:

tmm --clientciphers 'TLSv1_2+ECDHE_ECDSA+AES-GCM:TLSv1_2+ECDHE+AES-GCM:TLSv1_2+ECDHE_ECDSA+AES:TLSv1_2+ECDHE+AES:TLSv1_2+ECDHE_ECDSA+3DES:TLSv1_2+ECDHE+3DES:+SHA384'
       ID  SUITE                            BITS PROT    METHOD  CIPHER  MAC     KEYX
 0: 49195  ECDHE-ECDSA-AES128-GCM-SHA256    128  TLS1.2  Native  AES-GCM  SHA256  ECDHE_ECDSA
 1: 49199  ECDHE-RSA-AES128-GCM-SHA256      128  TLS1.2  Native  AES-GCM  SHA256  ECDHE_RSA
 2: 49162  ECDHE-ECDSA-AES256-SHA           256  TLS1.2  Native  AES     SHA     ECDHE_ECDSA
 3: 49187  ECDHE-ECDSA-AES128-SHA256        128  TLS1.2  Native  AES     SHA256  ECDHE_ECDSA
 4: 49161  ECDHE-ECDSA-AES128-SHA           128  TLS1.2  Native  AES     SHA     ECDHE_ECDSA
 5: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1.2  Native  AES     SHA     ECDHE_RSA
 6: 49191  ECDHE-RSA-AES128-SHA256          128  TLS1.2  Native  AES     SHA256  ECDHE_RSA
 7: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1.2  Native  AES     SHA     ECDHE_RSA
 8: 49160  ECDHE-ECDSA-DES-CBC3-SHA         192  TLS1.2  Native  DES     SHA     ECDHE_ECDSA
 9: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1.2  Native  DES     SHA     ECDHE_RSA
10: 49196  ECDHE-ECDSA-AES256-GCM-SHA384    256  TLS1.2  Native  AES-GCM  SHA384  ECDHE_ECDSA
11: 49200  ECDHE-RSA-AES256-GCM-SHA384      256  TLS1.2  Native  AES-GCM  SHA384  ECDHE_RSA
12: 49188  ECDHE-ECDSA-AES256-SHA384        256  TLS1.2  Native  AES     SHA384  ECDHE_ECDSA
13: 49192  ECDHE-RSA-AES256-SHA384          256  TLS1.2  Native  AES     SHA384  ECDHE_RSA

(Please note, that ECDHE is a shortcut for ECDHE_RSA. A keyword like ECDHE_RSA is not supported.
The cipher string above is 143 characters long. Some versions of TMOS truncate cipher strings.
Please check the release notes and see AskF5 SOL 11481.)

Configuring a proper cipher is a moving target and should be reviewed regularly depending on weak handshake, crypto and MAC protocols, the current capabilities of TMOS and your business needs.
Reviewing ciphers and running interoperability tests is mandatory when updating/upgrading your TMOS version.

For changing ciphers it is not recommended to modify the default client-ssl profile. Leave it as it is and create an own new master profile to be used as parent in all customized client-ssl profiles.
This approach will also allow changes to ciphers in case you are using multiple client-ssl profiles per virtual server to support server name indication (SNI).

Before touching ciphers I recommend reading the current TMOS release notes and some of the related AskF5 solutions (SOL13171, SOL17370, SOL15194, SOL13156).
Jason Rahm and John Wagnon wrote a series of articels for DevCentral focussing on SSL/TLS. You may want to start with Part 1 of the "SSL Profiles".
Search online for Ivan Ristics ebook on securing and testing SSL. Its definitely worth reading!

New cipher strings should be evaluated first in a staging environment i.e. versus the QUALYS online tool or others as provided i.e. by weakdh.org or SYMANTEC.
Monitor as well the performance graphs of your BIG-IP. Different ciphers may have a very different impact to the CPU.
Browser plugins like CALOMEL for Firefox allow a local quick analysis.
For local testing on your BIG-IP you can use the openssl s_client, curl and curl-apd.
These tools allow to specify ciphers and to reference local trusted and intermediate CA files.

The examples above (tested on TMOS v11.5.3HF2) must not be understood as recommendations.
They just demonstrate ways to build your ciphers and may reveal weaknesses when testing in real world and will definitely not be interoperable with all types of clients.

This post does not cover the hashing of certificates. It just discusses the hashing algorithm for message authentication in the cipher context.

The available keywords will vary depending on your version of TMOS.

Thanks in advance for providing feedback, additions, corrections.

Thats it. Thanks, Stephan

4
Rate this Discussion
Comments on this Discussion
Comment made 13-Dec-2015 by boneyard 5579
thanks Stephan, tagging this post to look back later.
0

Replies to this Discussion

placeholder+image

Viprion administrators should note that SHA256 and SHA384 aren't supported in Hardware. The bug ID is 501045.

0
placeholder+image

Regarding Johns response:
By ordering the ciphers you can get control on preferring a specific message authentication method (not to be confused with hashing for certs).
I.e the following cipher string would prevent using MD5 and use SHA, SHA256 and SHA384 in order:
"DEFAULT:!MD5:+SHA:+SHA256:+SHA384" (the prefix of + sends the associated method to the end of the resulting list allowing us to strip the +SHA from the list as it is the preferred method).
By changing the order you change the preference. I have seen testing tools giving a higher ranking with SHA256+ MAC.
So finally it depends on your business needs and platform capabilities.
Ask F5 SOL13213 lists hardware accelerated ciphers depending on H/W platform for TMOS v11/v12.
Ask F5 SOL13163 lists cipher support in the specific TMOS major/minor/maintenance releases in TMOS v12/v11.
Thanks, Stephan

0
Comments on this Reply
Comment made 14-Dec-2015 by nathan 7337
great article Stephan. SSL ciphers are a constant conversation at the moment so nice to get something very clear and concise on the matter. Note - i only found out last week that only 2000/4000 devices accelerated elliptic curve in hardware and not the others. It's down to the hardware chip apparently (Intel v Cavium).
0
Comment made 14-Dec-2015 by Stephan Manthey 3803
Thanks Nathan, I didnt got the chance to test different ciphers on different H/W platforms and to review the performance impact by now.
0
placeholder+image

I personally prefer to do cipher strings as whilelists. This gives tight control of what's supported and ensures that the ciphers stay the same when upgrading software versions. My typical go-to string is this:

ECDHE+AES-GCM:ECDHE+AES:RSA+AES-GCM:RSA+AES:RSA+3DES

The Viprion's don't support SHA256 and SHA384 in hardware which is required with with AES-GCM suites, so for them I ignore AES-GCM and force SHA-1:

ECDHE+AES+SHA:RSA+AES+SHA:RSA+3DES

Both of these will give an A rating on SSL labs.

0
Comments on this Reply
Comment made 14-Dec-2015 by Stephan Manthey 3803
You know you can do 'TLSv1_1+RSA+3DES:TLSv1_2+RSA+3DES'? This way you prevent usage of TLSv1 and should get no complaints about potential BEAST attacks. Same mechanism needs to be applied to other bulk crypto algorithms using CBC.
0
Comment made 14-Dec-2015 by John Heyer 400
I think the problem with disabling TLSv1 support with 3DES is it will leave IE8 unsupported. But that's a good tip; I didn't know you could specify TLS/SSL versions in the cipher string and had just been using the "options" field in the client SSL profile.
0
Comment made 15-Dec-2015 by Stephan Manthey 3803
By adding 'TLSv1+RC4+SHA:!EXPORT' you would get the RC4-SHA for these guys. Make sure to disable the EXPORT ciphers.
0
placeholder+image

Summarized and updated the content of this post into a cheat sheet and posted it here on DevCentral.

0