This is part 4 in a series of articles covering the BIG-IP LTM SSL profiles.
We’re working our way through the profile options, and this week, we’re taking a look at the SSL ciphers.
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
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.
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|
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:
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
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:
I’ve drawn from several solutions over at AskF5, here’s the short list:
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.