SSL Profiles Part 4: Cipher Suites

Introduction

This is part 4 in a series of articles covering the BIG-IP LTM SSL profiles.

  1. SSL Overview and Handshake
  2. SSL Certificates
  3. Certificate Chain Implementation
  4. Cipher Suites
  5. SSL Options
  6. SSL Renegotiation
  7. Server Name Indication
  8. Client Authentication
  9. Server Authentication
  10. All the "Little" Options

We’re working our way through the profile options, and this week, we’re taking a look at the SSL ciphers.

What is a Cipher Suite?

A cipher suite is a set of ciphers used in the privacy, authentication, and integrity of data passed between a server and client in an SSL session.  Any given session uses one cipher, which is negotiated in the handshake.  The components of the cipher are

  • Key Exchange Algorithm (RSA or DH) – symmetric (same key for encryption/decryption) or asymmetric (shared public key for encryption, protected private key for decryption)
  • Authentication Algorithm (RSA or DSS.  Note that with RSA, Key Exchange and Authentication are combined) – Used for authenticating the server and/or client.  X.509 certificates in the case of SSL.
  • Encryption Algorithm (DES, 3DES, AES, RC4) – Used to encrypt the message payload
  • Message Authentication Code (MAC) Digest Algorithm (MD5, SHA-1) – Used for message integrity

So in looking at the ciphers on my v10.2 box:

[root@golgotha:LICENSE EXPIRED] config # 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

You can see that for the AES256-SHA cipher, key exchange & authentication are RSA, encryption is AES, and the mac is SHA-1.  Notice that all the MD5 ciphers are missing?  Beginning in v10.2, all the MD5 ciphers are removed by default.  You can still use them, but you’ll need to make some changes to your cipher list.  Larger key lengths (256 versus 128) makes for more complicated math and is thus a) harder to crack and b) more CPU intensive.  Thankfully, all BIG-IP platforms (with LTM VE the obvious exception) have hardware offloading of this processing.  You’ll want to be careful in the ciphers you offer, however, as some are not fully offloaded.  The list is provided in solution 6739, which is referenced below in the resources section.

Setting the Cipher Options in the profile

The Ciphers field in the SSL profile by default has a single word: DEFAULT.  DEFAULT means different things in different versions.  If you want to avoid surprises when upgrading, you might consider specifying your parameters.  The table below shows the variances in *DEFAULT* behavior between versions

v9.4.x – v10.0.1 DEFAULT !SSLv2:ALL:!ADH:@SPEED
v10.1.x DEFAULT !SSLv2:ALL:!DH:!ADH:!EDH:@SPEED
v10.2.x DEFAULT !SSLv2:ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:@SPEED

This shows the progression through versions.  First, EDH ciphers were eliminated, then in v10.2, low strength and MD5 ciphers were eliminated.  Also, notice that @SPEED keyword?  That will order all the ciphers by speed.  If you desire the order to be by strongest cipher instead, you can use the @STRENGTH keyword.    As for the format of the list itself, the cipher strings should be separated by colons and can feature the accepted cipher strings (listed here) and these formatting options:

  • “!” – these ciphers are permanently deleted from the list and cannot reappear in the list even if explicitly stated.
  • “-“ - these ciphers are deleted from the list but can be re-added by later options
  • “+” – these ciphers are moved to the end of the list.

Examples

So if you wanted to use the v10.2 default but order by strength instead of speed, you could use this string:

[root@golgotha:LICENSE EXPIRED] config # tmm --clientciphers '!SSLv2:ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:@STRENGTH'
     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:  53 AES256-SHA                      256  DTLS1  Native AES    SHA    RSA
 3:  10 DES-CBC3-SHA                    192  SSL3  Native DES    SHA    RSA
 4:  10 DES-CBC3-SHA                    192  TLS1  Native DES    SHA    RSA
 5:  10 DES-CBC3-SHA                    192  DTLS1  Native DES    SHA    RSA
 6:   5 RC4-SHA                         128  SSL3  Native RC4    SHA    RSA
 7:   5 RC4-SHA                         128  TLS1  Native RC4    SHA    RSA
 8:  47 AES128-SHA                      128  SSL3  Native AES    SHA    RSA
 9:  47 AES128-SHA                      128  TLS1  Native AES    SHA    RSA
10:  47 AES128-SHA                      128  DTLS1  Native AES    SHA    RSA

Limiting only the high security ciphers and preventing any of the SSLv2 ciphers and any ciphers without authentication or encryption, while ordering by strength:

[root@golgotha:LICENSE EXPIRED] config # tmm --clientciphers 'TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:@STRENGTH'
     ID SUITE                          BITS  PROT  METHOD CIPHER MAC    KEYX
 0:  53 AES256-SHA                      256  TLS1  Native AES    SHA    RSA
 1:  58 ADH-AES256-SHA                  256  TLS1  Compat AES    SHA    ADH
 2:  55 DH-RSA-AES256-SHA               256  TLS1  Compat AES    SHA    DH/RSA
 3:  57 DHE-RSA-AES256-SHA              256  TLS1  Compat AES    SHA    EDH/RSA
 4:  10 DES-CBC3-SHA                    192  TLS1  Native DES    SHA    RSA
 5:  27 ADH-DES-CBC3-SHA                192  TLS1  Compat DES    SHA    ADH
 6:  16 DH-RSA-DES-CBC3-SHA             192  TLS1  Compat DES    SHA    DH/RSA
 7:  22 DHE-RSA-DES-CBC3-SHA            192  TLS1  Compat DES    SHA    EDH/RSA

Testing

Once the cipher list is established, I can test from the command line utilizing the s_client option in the openssl command:

[root@golgotha:Active] config # openssl s_client -cipher 'AES256-SHA' -connect 10.10.20.112:443
CONNECTED(00000003)
depth=0 /C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com
   i:/C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICNjCCAZ+gAwIBAgIBADANBgkqhkiG9w0BAQUFADBhMQswCQYDVQQGEwJVUzEL
MAkGA1UECBMCSUwxDTALBgNVBAcTBHRlc3QxDTALBgNVBAoTBHRlc3QxDTALBgNV
BAsTBHRlc3QxGDAWBgNVBAMTD3Rlc3QudGVzdGNvLmNvbTAeFw0xMDA5MjcxOTUx
MTBaFw0xMTA5MjcxOTUxMTBaMGExCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJJTDEN
MAsGA1UEBxMEdGVzdDENMAsGA1UEChMEdGVzdDENMAsGA1UECxMEdGVzdDEYMBYG
A1UEAxMPdGVzdC50ZXN0Y28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDgHNoyzfUUwchuLfUfj8cJKISY8v8LBQ8NhzK3sO4GSi9K/iHP4n6X2b4XsN3S
288py0H6w10kNXQBu9yCT0SZHlJl5aZ9BTxCupAwu356W4nc1YEzXb6YgIoPLdU7
S+rOIekjSVbij+vES42v7A91wlw8kTxSSfwv5NxhHgseIQIDAQABMA0GCSqGSIb3
DQEBBQUAA4GBALoT8R3Bz2ZSWGjnTAOT07W13aYdMO5lcyQ05uurL/X0SooN4jes
4a4+/pyqHw2owZzmTxUiRxLIAw49lLzhyme38egOIx6svwPl05KcpfHbaoXJEfKx
PDGAOHGNxRmDuvMVNGGmdBtXmlRokEqzHAbJTHQZLOWQwuiCM8NcTIF3
-----END CERTIFICATE-----
subject=/C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com
issuer=/C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com
---
No client certificate CA names sent
---
SSL handshake has read 732 bytes and written 244 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 9ECE925CED90B4CF2EA2E8D2DD62FDCF40D8A1BF4E7A3A24588BC5A7AB21221B
    Session-ID-ctx:
    Master-Key: 55C17443918E9B8B0B15443C37DD4B3C6A7E8EDF6F2E77EA4CC3BD4E9E5682F7700DDCFDDBB3F10CD7E6B13FD60EB836
    Key-Arg   : None
    Start Time: 1292452103
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)

You can see that the cipher I selected from the client (the only one the client would accept) is utilized for the active session.  Now, if I make a request utilizing an MD5 cipher, it errors out if (as in this case) the default v10.2 cipher list is in place:

[root@golgotha:Active] config # openssl s_client -cipher 'RC4-MD5' -connect 10.10.20.112:443
CONNECTED(00000003)
20193:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:578:

Important Resources

I’ve drawn from several solutions over at MyF5, here’s the short list:

Conclusion

There’s a lot going on with ciphers, and any one article can’t do them justice.  I didn’t even approach the discussion of why certain ciphers are good/bad/ugly.  A study on cryptography is out of scope, and I’m not an authority in that area any.  That said, the SSL profiles are extremely flexible in allowing cipher configurations of your choice, per virtual if desired.  In the next article, we’ll move another checkbox down the profile and take a look at the SSL options field.

Updated Mar 25, 2023
Version 2.0

Was this article helpful?

7 Comments

  • Hi Jason,

     

    Good post but I´m wondering of some things here.

     

    I have always used @strenght in other plattforms (like nortel SSL gateway,etc.) but F5 said before that you shouldn´t use it. Has this changed in 10.2?

     

    IMHO it´s better to use the syntax tmm --clientciphers 'xxxx' instead of openssl because you then will see if the ciphers are in compat or native mode.

     

    And It´s not the same ciphers if you check these syntax.

     

  • Do you have a reference that @strength should not be used? I can add it to the resources section. Also, you're right, I should have used tmm --clientciphers, I've updated the article to reflect that. Thanks for the feedback!
  • Hi jason,

     

     

    Sorry I didn´t get back so soon (vacation).

     

    However, I´m pretty sure that it was a SOL for this but I have searched and I can´t find it ( and I talked to a f5 tech guy at that time about this when I found a bug i serverssl and ciphers not using native rc4-md5). if I remember it right it was something with openssl-f5 and IE6.

     

    But now this will now not be a problem i guess, no proof to show =)

     

     

    Adam
  • I personally like to use

    !DHE:ECDHE_ECDSA+AES-GCM:ECDHE+AES-GCM:ECDHE_ECDSA:ECDHE:DEFAULT

    for my client SSL profiles. It gives me pretty high rankings in the SSL security scanners 🙂

  • You can test ciphers directly from the shell. For instance, tmm --clientciphers '!SSLv2:!SSLv3:!NULL:!ADH:!LOW:!EXP:!MD5:SHA256:TLSv1_2:TLSv1_1:TLSv1:-TLSv1_1+RC4:-TLSv1_2+RC4'