Forum Discussion

Bubbagump_12531's avatar
Bubbagump_12531
Icon for Nimbostratus rankNimbostratus
Sep 21, 2015

SSL Handshake failed

We noticed that we have a lot more SSLv3 traffic than we would expect. We want to phase out SSLv3 and we're looking at the SSLClient profile metrics and found ~12% of our users are on SSLv3 which is nuts. In digging a bit more we're finding

 

tmm2[16184]: 01260013:6: SSL Handshake failed for TCP 1.2.3.4:1234 -> 10.1.1.1:443

 

errors in /var/log/ltm

 

My initial thought was perhaps this is an unclean shutdown issue. I enabled strict resume and there was no improvement.

 

Another curious piece is that from our Apache logs, it appears those using SSLv3 and having handshake error have a user-agent string from Linux hosts. Example:

 

"Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0"

 

Handshake errors may be unrelated. But Firefox 38 should have no issue connecting via TLS. Anyone have any ideas?

 

5 Replies

  • I have been through that article several times and it isn't much help. From what I can tell in my TCPdumps is that the Client Hello comes in, the Server Hello goes out, and immediately afterwards a RST ACK comes from the client. The handshakes errors may indeed be a red herring.

     

    Again, the issue I am chasing is how in the world 10% of our traffic is still SSLv3 when our user-agent logs would lead us to believe our customers should be able to use TLS. So the question is, why are they negotiating SSLv3 and why does this seem to be limited to Linux clients?

     

  • What's your cipher string?

     

    The client suggests the cipher list, but the server chooses (according to the order of your cipher string).

     

    This page has great information about the cipher strings:

     

    https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13171.html

     

    User agent could possibly be taken with a grain of salt too as it could be easily faked. Have you checked if a majority of the clients comes from the same IP? Could be a scraper posing as FF.

     

    Best way to really check it out could be to install the same version of FF yourself and check out the cipher negotiation. :)

     

    /Patrik

     

  • This is 11.5.3 and the string is DEFAULT:@STRONG:SSLv3. I would expect this to shove everyone towards TLS. Am I wrong in my interpretation?

     

  • I agree, it should.

    I'm also running 11.5.3. Here's my default ciphers:

     user@LB:  tmm --clientciphers DEFAULT
           ID  SUITE                            BITS PROT    METHOD  CIPHER  MAC     KEYX
     0:    61  AES256-SHA256                    256  TLS1.2  Native  AES     SHA256  RSA
     1:    53  AES256-SHA                       256  TLS1    Native  AES     SHA     RSA
     2:    53  AES256-SHA                       256  TLS1.1  Native  AES     SHA     RSA
     3:    53  AES256-SHA                       256  TLS1.2  Native  AES     SHA     RSA
     4:    53  AES256-SHA                       256  DTLS1   Native  AES     SHA     RSA
     5:    60  AES128-SHA256                    128  TLS1.2  Native  AES     SHA256  RSA
     6:    47  AES128-SHA                       128  TLS1    Native  AES     SHA     RSA
     7:    47  AES128-SHA                       128  TLS1.1  Native  AES     SHA     RSA
     8:    47  AES128-SHA                       128  TLS1.2  Native  AES     SHA     RSA
     9:    47  AES128-SHA                       128  DTLS1   Native  AES     SHA     RSA
    10:    10  DES-CBC3-SHA                     192  TLS1    Native  DES     SHA     RSA
    11:    10  DES-CBC3-SHA                     192  TLS1.1  Native  DES     SHA     RSA
    12:    10  DES-CBC3-SHA                     192  TLS1.2  Native  DES     SHA     RSA
    13:    10  DES-CBC3-SHA                     192  DTLS1   Native  DES     SHA     RSA
    14:     5  RC4-SHA                          128  TLS1    Native  RC4     SHA     RSA
    15:     5  RC4-SHA                          128  TLS1.1  Native  RC4     SHA     RSA
    16:     5  RC4-SHA                          128  TLS1.2  Native  RC4     SHA     RSA
    17: 49192  ECDHE-RSA-AES256-SHA384          256  TLS1.2  Native  AES     SHA384  ECDHE_RSA
    18: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1    Native  AES     SHA     ECDHE_RSA
    19: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1.1  Native  AES     SHA     ECDHE_RSA
    20: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1.2  Native  AES     SHA     ECDHE_RSA
    21: 49191  ECDHE-RSA-AES128-SHA256          128  TLS1.2  Native  AES     SHA256  ECDHE_RSA
    22: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1    Native  AES     SHA     ECDHE_RSA
    23: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1.1  Native  AES     SHA     ECDHE_RSA
    24: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1.2  Native  AES     SHA     ECDHE_RSA
    25: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1    Native  DES     SHA     ECDHE_RSA
    26: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1.1  Native  DES     SHA     ECDHE_RSA
    27: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1.2  Native  DES     SHA     ECDHE_RSA
    

    Looking at the article previously mentioned that would make your list:

    !SSLv2:!SSLv3:!MD5:!EXPORT:RSA+AES:RSA+3DES:RSA+RC4:ECDHE+AES:ECDHE+3DES:ECDHE+RC4:@STRONG:SSLV3

    The article says:

    Note: When you use the ! symbol preceding a cipher, the SSL profile permanently removes the cipher
    from the cipher list, even if it is explicitly stated later in the cipher string. 
    When you use the - symbol preceding a cipher, the SSL profile removes the cipher from the cipher list, 
    but it can be added back to the cipher list if there are later options that allow it.
    

    That would indicate that SSLv3 is not allowed at all. Have you looked around for other profiles with custom cipher strings?

    /Patrik