SSL handshake failure

is there any suspicious in /var/log/ltm?

 

 

have you seen the problem in new ssl session (not resume ssl session)?

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

@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.

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

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.

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.

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?

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?

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 :)

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