Forum Discussion
smp_86112
Cirrostratus
CirrostratusServer SSL Profile ciphers
I'm using the following Ciphers string in a server SSL profile on my 11.4.1HF3 LTM:
DEFAULT:-TLSv1_1:-TLSv1_2The resulting ciphers list is this:
Active:Changes Pending] ~ tmm --serverciphers 'DEFAULT:-TLSv1_1:-TLSv1_2'
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
11: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1 Native AES SHA ECDHE_RSA
12: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA
13: 49170 ECDHE-RSA-DES-CBC3-SHA 192 TLS1 Native DES SHA ECDHE_RSAYet when I examine the CLIENTHELLO on the serverside of the connection on the wire, I see the LTM presents a much larger list of available ciphers:
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014)
Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Shouldn't the LTM only display the ciphers that are output in the
tmm --serverciphers 'DEFAULT:-TLSv1_1:-TLSv1_2'Beyond this, I see that adding the @STRENGTH keyword to the Ciphers string does not change the order that the LTM presents the list of ciphers to the server. I'm wondering if I just don't understand something, or if this is bad LTM behavior.
nitassEmployee
this is mine.
config [root@B5200-R78-S13:Active:Standalone] config tmsh show sys version|head Sys::Version Main Package Product BIG-IP Version 11.4.1 Build 637.0 Edition Hotfix HF3 Date Fri Jan 17 13:32:07 PST 2014 Hotfix List [root@B5200-R78-S13:Active:Standalone] config tmsh root@(B5200-R78-S13)(cfg-sync Standalone)(Active)(/Common)(tmos) list ltm virtual bar ltm virtual bar { destination 101.101.101.173:https ip-protocol tcp mask 255.255.255.255 pool foo profiles { clientssl { context clientside } myserverssl { context serverside } tcp { } } source 0.0.0.0/0 source-address-translation { type automap } vs-index 2 } root@(B5200-R78-S13)(cfg-sync Standalone)(Active)(/Common)(tmos) list ltm pool foo ltm pool foo { members { 200.200.200.101:https { address 200.200.200.101 } } } root@(B5200-R78-S13)(cfg-sync Standalone)(Active)(/Common)(tmos) list ltm profile server-ssl myserverssl ltm profile server-ssl myserverssl { app-service none ciphers DEFAULT:-TLSv1_1:-TLSv1_2 } cipher [root@B5200-R78-S13:Active:Standalone] config tmm --serverciphers "DEFAULT:-TLSv1_1:-TLSv1_2" 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 11: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1 Native AES SHA ECDHE_RSA 12: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA 13: 49170 ECDHE-RSA-DES-CBC3-SHA 192 TLS1 Native DES SHA ECDHE_RSA trace New TCP connection 2: 200.200.200.172(57026) <-> 200.200.200.101(443) 2 1 1398708282.8530 (0.0016) C>SV3.1(75) Handshake ClientHello Version 3.1 random[32]= f8 9c 48 5c 7b e5 2b 6e 83 04 87 be 32 6c f7 c7 42 fe b8 3c d9 8f ee 56 b5 bd 70 48 1f 37 50 56 cipher suites TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0xc013 Unknown value 0xc014 Unknown value 0xc012 Unknown value 0xff compression methods NULL- nitass
is it health monitor?
- nitass
this is default https monitor.
[root@B5200-R78-S13:Active:Standalone] config ssldump -Aed -nni 0.0 port 443 New TCP connection 1: 200.200.200.172(56861) <-> 200.200.200.101(443) 1 1 1398708564.6197 (0.0015) C>SV3.1(128) Handshake ClientHello Version 3.1 random[32]= 53 5e 99 54 af 65 1a 08 b9 5c 84 ef a5 03 93 9b 19 14 27 d1 f7 b7 47 82 b4 2a 6b 54 98 af 6f 8e resume [32]= 9d 19 e3 84 9d d1 26 7d e1 a3 7a 7b 55 49 3d 62 fd 10 2c 2c 76 0d f2 72 b7 c2 c3 05 dc d7 7f c2 cipher suites TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA Unknown value 0x45 Unknown value 0x44 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xff compression methods unknown value NULLps. sorry to spam answer. format is messed up when combining them into one post.
smp_86112is it health monitor?
YES! This VIP is snatted and my tcpdump command mistakenly EXCLUDED the floating self-ip, leaving only monitor traffic in my trace. I just took another trace and verified the LTM only sends the list of 7 matching TLS ciphers in the
output. This is what I expected. Thanks very much for setting me straight!tmm --serverciphers 'DEFAULT:-TLSv1_1:-TLSv1_2'This leads me to another question...what makes the LTM decide to "decide" to use TLS on the serverside of the connection? Is that because the client on the clientside requested to use TLS (which it does), and it is required to maintain the same protocol on both sides?
nitass_89166Noctilucent
what makes the LTM decide to "decide" to use TLS on the serverside of the connection? Is that because the client on the clientside requested to use TLS (which it does), and it is required to maintain the same protocol on both sides?
i understand ltm uses the highest version first. i do not think maintaining the same protocol version is needed.
- smp_86112> i understand ltm uses the highest version first Intuitively this makes sense, but that implies some sort of defined order. And so I would expect the output of the `tmm --serverciphers` command to display the list in that priority, but it doesn't. Perhaps I expect too much.
- nitass
what makes the LTM decide to "decide" to use TLS on the serverside of the connection? Is that because the client on the clientside requested to use TLS (which it does), and it is required to maintain the same protocol on both sides?
i understand ltm uses the highest version first. i do not think maintaining the same protocol version is needed.
- smp_86112> i understand ltm uses the highest version first Intuitively this makes sense, but that implies some sort of defined order. And so I would expect the output of the `tmm --serverciphers` command to display the list in that priority, but it doesn't. Perhaps I expect too much.