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
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:
Limiting only the high security ciphers and preventing any of the SSLv2 ciphers and any ciphers without authentication or encryption, while ordering by strength:
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:
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.
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!
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 😃
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'
