Forum Discussion

mahnsc's avatar
mahnsc
Icon for Nimbostratus rankNimbostratus
Aug 08, 2018

Unexpected SSL Client Behavior

I have an SSL Client profile with a cipher list that is sorted by preferred cipher order:

AES256-SHA256:AES256-SHA:DES-CBC3-SHA:AES128-SHA256:AES128-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-CBC-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA

The unexpected thing I'm seeing is that identically configured java clients using the exact same configuration settings are negotiating to the VIP using different TLS protocols and ciphers. Does anyone know why this might be happening? The other odd thing is that if the client connect using TLS1.0 and AES256-SHA, it never changes for that client IP. I have included a snippet from the web server logs where we pass the Protocol and Cipher with an iRule that is on that destination VIP. I'm not setting any specific Options in the ssl client profile but I did recently try disabling TLS1.0 and TLS1.1 in the client profile but some of these hosts connected fine while others tried connecting using TLS1.0 and got handshake failures.

Log entries:

2018-08-02 14:38:26.357 "aaa.bbb.85.167" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
2018-08-02 13:03:57.370 "aaa.bbb.85.155" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
2018-08-02 12:54:32.096 "aaa.bbb.85.154" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-02 11:35:56.030 "aaa.bbb.85.156" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-02 10:26:19.295 "aaa.bbb.85.157" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-02 13:03:54.764 "aaa.bbb.85.155" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
2018-08-02 13:03:55.279 "aaa.bbb.85.155" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
2018-08-02 13:03:57.370 "aaa.bbb.85.155" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
2018-08-02 13:05:46.252 "aaa.bbb.85.218" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA256"
2018-08-02 13:05:46.798 "aaa.bbb.85.218" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA256"
2018-08-02 13:05:47.282 "aaa.bbb.85.218" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA256"
2018-08-02 13:05:49.279 "aaa.bbb.85.218" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA256"
2018-08-01 02:41:24.365 "aaa.bbb.85.220" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA256"
2018-08-01 02:41:25.020 "aaa.bbb.85.220" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA256"
2018-08-01 02:41:25.503 "aaa.bbb.85.220" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA256"
2018-08-01 02:41:27.937 "aaa.bbb.85.220" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA256"
2018-08-01 05:46:41.223 "aaa.bbb.85.223" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-01 05:46:41.722 "aaa.bbb.85.223" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-01 05:46:42.159 "aaa.bbb.85.223" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-01 05:46:44.421 "aaa.bbb.85.223" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-01 05:57:07.961 "aaa.bbb.85.223" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-01 05:57:08.460 "aaa.bbb.85.223" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-01 05:57:08.944 "aaa.bbb.85.223" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-01 05:57:10.956 "aaa.bbb.85.223" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1.2" "AES256-SHA"
2018-08-01 06:01:32.774 "aaa.bbb.85.222" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
2018-08-01 06:01:33.305 "aaa.bbb.85.222" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
2018-08-01 06:01:33.820 "aaa.bbb.85.222" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
2018-08-01 06:01:40.231 "aaa.bbb.85.222" POST /access/scripts/broker.asp - "Java/1.7.0_45" 200 "TLSv1" "AES256-SHA"
application delivery
BIG-IP
LTM

2 Replies

Sort By
  • Tyler_Shaw_9498's avatar
    Tyler_Shaw_9498
    Historic F5 Account
    Aug 09, 2018

    The error with that specific client is due to the fact that Java 1.7 prior to version 1.7.0_131-b31 did not enable TLS 1.2 by default.

     

    From the release notes:

     

    Add TLS v1.1 and v1.2 to the client list of default-enabled protocols TLSv1.2 and TLSv1.1 are now enabled by default on the TLS client end-points. This is similar behavior to what already happens in JDK 8 releases.

     

    Release notes here: https://www.oracle.com/technetwork/java/javase/7u131-relnotes-3338543.html

     

  • Tyler_Shaw_9498's avatar
    Tyler_Shaw_9498
    Historic F5 Account
    Aug 09, 2018

    The BIG-IP should always use the server cipher list as the sole authority on the order of chosen ciphers (https://support.f5.com/csp/article/K12390). Given that, I suspect that the clients are not offering up the stronger ciphers as available. If the clients are offering up the same client hello, the BIG-IP will choose the same way every time.

     

    You can see the list of ciphers offered by the client in a packet capture by looking at "Client Hello" packet in wireshark. It will be the first packing after the TCP handshake is complete.