Forum Discussion

W__Tout_99150's avatar
W__Tout_99150
Icon for Nimbostratus rankNimbostratus
Mar 07, 2013

SSL handshake failure

Hello,

 

we're seeing a weird behaviour during SSL handshake where the client (on an Android mobile device) sends the ClientHello to the LB but the LB does not send back the ServerHello. We see the clientHello come in and then 60 seconds later a "TCP RST" sent by the LB. We considered that it might be related to session resume but we found out that most of the sessions are resumed successfully.

 

I read online (http://ask.wireshark.org/questions/14419/ssl-record-layer-vs-sslv3-record-layer) that "In the transition from SSLv2 to SSLv3 backward compatibility was ensured by using a SSLv2 record layer header. But today most servers won't allow (the insecure) SSLv2 protocol, so if the client tries a SSLv2 compatible handshake, the server just denies the connection". I tried disabling SSLv2 by adding the following lines to my clientssl profile:

 

 

ciphers "!SSLv2:ALL:!DH:!ADH:!EDH:@SPEED"

 

renegotiate enable

 

 

This did not have any impact as we kept encountering the same behaviour of no ServerHello sent by the LB. I also checked whether we are hitting our SSL TPS limits but found that we are nowhere near.

 

 

I have attached the tcpdump of the failing ClientHello. Has anybody come across this type of behaviour? what could be the cause? Is that possibly a bug in F5?

 

 

Our F5 is running with:

 

 

Kernel:

 

Linux 2.6.18-164.11.1.el5.1.0.f5app

 

Package:

 

BIG-IP Version 10.2.1 297.0

 

Final Edition

 

 

 

APM
app sec
security

11 Replies

Sort By
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Mar 08, 2013
    is there any suspicious in /var/log/ltm?

     

     

    have you seen the problem in new ssl session (not resume ssl session)?
  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Mar 08, 2013
    Just a thought from me.

     

     

    Does it work from a browser on a PC, for example, and only failing on an Android?

     

    What key length is the certificate, 1024 or 2048?

     

     

    Rgds,

     

    N
  • W__Tout_99150's avatar
    W__Tout_99150
    Icon for Nimbostratus rankNimbostratus
    Mar 08, 2013
    @Nitass, there is nothing logged in /var/log/ltm for the failing requests and the problem is observed only with resumes.

     

     

    @Nathan, the certificate is a wildcard certificate with a key length of 2048. It works from both a browser and from Android devices.

     

     

    We only see the problem occasionally but consistently with ssl session resumes (sessionid included in ClientHello) and with "SSL Record Layer" displayed under "Secure Sockets Layer" as can be seen in the attached file. No failures were/are observed with "SSLv3 Record Layer" or "TLSv1 Record Layer" be it a new ssl connection or a resume.
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Mar 09, 2013
    can you try to disable tls1 (i.e. using ciphers: !SSLv2:ALL:!DH:!ADH:!EDH:@SPEED:!TLSv1)? 

    [root@B3600-R67-S41:Active] config  b version|grep -iA 1 version
BIG-IP Version 10.2.1 511.0
Hotfix HF3 Edition

[root@B3600-R67-S41:Active] config  tmm --clientciphers '!SSLv2:ALL:!DH:!ADH:!EDH:@SPEED:!TLSv1'
     ID SUITE                          BITS  PROT  METHOD CIPHER MAC    KEYX
 0:   4 RC4-MD5                         128  SSL3  Native RC4    MD5    RSA
 1:   5 RC4-SHA                         128  SSL3  Native RC4    SHA    RSA
 2:  47 AES128-SHA                      128  SSL3  Native AES    SHA    RSA
 3:  47 AES128-SHA                      128  DTLS1  Native AES    SHA    RSA
 4:  53 AES256-SHA                      256  SSL3  Native AES    SHA    RSA
 5:  53 AES256-SHA                      256  DTLS1  Native AES    SHA    RSA
 6:  10 DES-CBC3-SHA                    192  SSL3  Native DES    SHA    RSA
 7:  10 DES-CBC3-SHA                    192  DTLS1  Native DES    SHA    RSA
 8:   9 DES-CBC-SHA                      64  SSL3  Native DES    SHA    RSA
 9:   9 DES-CBC-SHA                      64  DTLS1  Native DES    SHA    RSA
10:  96 EXP1024-RC4-MD5                  56  SSL3  Native RC4    MD5    RSA
11: 100 EXP1024-RC4-SHA                  56  SSL3  Native RC4    SHA    RSA
12:  98 EXP1024-DES-CBC-SHA              56  SSL3  Native DES    SHA    RSA
13:  98 EXP1024-DES-CBC-SHA              56  DTLS1  Native DES    SHA    RSA
14:   3 EXP-RC4-MD5                      40  SSL3  Native RC4    MD5    RSA
15:   8 EXP-DES-CBC-SHA                  40  SSL3  Native DES    SHA    RSA
16:   8 EXP-DES-CBC-SHA                  40  DTLS1  Native DES    SHA    RSA
17:  97 EXP1024-RC2-CBC-MD5              56  SSL3  Compat RC2    MD5    RSA
18:  97 EXP1024-RC2-CBC-MD5              56  DTLS1  Compat RC2    MD5    RSA
19:   6 EXP-RC2-CBC-MD5                  40  SSL3  Compat RC2    MD5    RSA
20:   6 EXP-RC2-CBC-MD5                  40  DTLS1  Compat RC2    MD5    RSA
  • W__Tout_99150's avatar
    W__Tout_99150
    Icon for Nimbostratus rankNimbostratus
    Mar 12, 2013
    No we have not as we definitely want to keep using TLSv1. Android expects the server, LB in our case, to be compliant with TLS. Anything else are incompatibility fall-back modes.
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Mar 13, 2013
    No we have not as we definitely want to keep using TLSv1. Android expects the server, LB in our case, to be compliant with TLS. Anything else are incompatibility fall-back modes.sorry to not explain properly. i have seen a bug in the past which happens on tls1 but i am not sure if it is your case. so, i just want to try.
  • W__Tout_99150's avatar
    W__Tout_99150
    Icon for Nimbostratus rankNimbostratus
    Mar 13, 2013
    so I tried disabling TLS1 as suggested. The "tmm" command output is as follows:

     

     

    [root@suwmt2lb01:Active] tmp tmm --clientciphers '!SSLv2:ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:@SPEED:!TLSv1'

     

    ID SUITE BITS PROT METHOD CIPHER MAC KEYX

     

    0: 5 RC4-SHA 128 SSL3 Native RC4 SHA RSA

     

    1: 47 AES128-SHA 128 SSL3 Native AES SHA RSA

     

    2: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA

     

    3: 53 AES256-SHA 256 SSL3 Native AES SHA RSA

     

    4: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA

     

    5: 10 DES-CBC3-SHA 192 SSL3 Native DES SHA RSA

     

    6: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA

     

     

    The curious thing is that this did not seem to change anything as we were still observing the problem and even TLSv1 was still being used. Is that normal? Did I miss something?
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Mar 13, 2013
    so I tried disabling TLS1 as suggested. The "tmm" command output is as follows: how did you disable tls1? you did change ciphers setting in clientssl profile, didn't you?
  • W__Tout_99150's avatar
    W__Tout_99150
    Icon for Nimbostratus rankNimbostratus
    Mar 13, 2013
    My bad. I thought I did. After really pushing the profile changes, we stopped seeing the problem. so I guess that means we have the bug you referred to. Can you provide more details on that bug and possible workarounds. Short of disabling TLS1 that is :)
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Mar 14, 2013
    this is the bug i referred. you may open a case to verify if you are experiencing this bug indeed.

     

     

    Bug 337378 - Client SSL COMPAT stack fails to handle large size extensions in TLS1 handshake.

     

     

    sol12248: Clients may experience intermittent connectivity to an SSL-enabled virtual server that uses compat ciphers

     

    http://support.f5.com/kb/en-us/solutions/public/12000/200/sol12248.html