Forum Discussion

rafaelbn_305907's avatar
rafaelbn_305907
Icon for Nimbostratus rankNimbostratus
May 06, 2018

ssldump first connection doesn't seem to transfer any data

Hello Devs!

When a client connects using IEv11, the first and second TLS connections does not seen to transfer any data. The application is working just fine. I'm just curious about this...

Here is the ssldump of it:

[root@bigip1:Active:Disconnected] config  ssldump -nni 0.0 -A host 192.168.1.43
New TCP connection 1: 192.168.1.224(23180) <-> 192.168.1.43(443)
1 1  0.0023 (0.0023)  C>SV3.1(172)  Handshake
      ClientHello
        Version 3.3 
        random[32]=
          db 7d af 76 a5 0b 3c 46 6a 14 43 4f c7 a3 10 80 
          07 a7 de 32 0a 0e 5a bf 02 a4 95 b8 bd c7 02 1d 
        cipher suites
        TLS_RSA_WITH_AES_256_GCM_SHA384
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA256
        TLS_RSA_WITH_AES_128_CBC_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        compression methods
                  NULL
1 2  0.0024 (0.0000)  S>CV3.3(81)  Handshake
      ServerHello
        Version 3.3 
        random[32]=
          f6 5a d2 b7 96 30 50 58 84 70 75 7f 38 64 74 8f 
          49 b0 87 54 19 02 fb 94 a2 9a 5f dd 1a 5e f0 19 
        session_id[32]=
          2a 80 ec 5b ff 45 e0 be 13 49 26 63 66 8d 88 46 
          06 76 28 99 38 b2 24 3d 8f 5f 8b 29 36 1d d8 57 
        cipherSuite         TLS_RSA_WITH_AES_256_GCM_SHA384
        compressionMethod                   NULL
1 3  0.0024 (0.0000)  S>CV3.3(956)  Handshake
      Certificate
1 4  0.0024 (0.0000)  S>CV3.3(4)  Handshake
      ServerHelloDone
1 5  0.0048 (0.0024)  C>SV3.3(262)  Handshake
      ClientKeyExchange
1 6  0.0048 (0.0000)  C>SV3.3(1)  ChangeCipherSpec
1 7  0.0048 (0.0000)  C>SV3.3(40)  Handshake
1 8  0.0078 (0.0029)  S>CV3.3(1)  ChangeCipherSpec
1 9  0.0078 (0.0000)  S>CV3.3(40)  Handshake
1    0.0158 (0.0079)  C>S  TCP FIN
1    0.0159 (0.0000)  S>C  TCP FIN
New TCP connection 2: 192.168.1.224(23182) <-> 192.168.1.43(443)
2 1  0.0024 (0.0024)  C>SV3.1(172)  Handshake
      ClientHello
        Version 3.3 
        random[32]=
          42 2a 47 8e 53 9c e4 da 41 27 7a cb be 18 2b 25 
          a9 3e dd 0b f1 da 8c 14 a6 5a 6e 26 5e 8a 1b b8 
        cipher suites
        TLS_RSA_WITH_AES_256_GCM_SHA384
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA256
        TLS_RSA_WITH_AES_128_CBC_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        compression methods
                  NULL
2 2  0.0024 (0.0000)  S>CV3.3(81)  Handshake
      ServerHello
        Version 3.3 
        random[32]=
          68 2f 0b e4 5b 3d 25 7a 74 69 d1 f4 1b 00 f2 e0 
          62 73 d7 23 bb e4 3f 56 be b3 70 7c 48 d2 58 60 
        session_id[32]=
          31 dd 8b 6e f4 d1 ef 82 f9 05 a0 d6 3d 78 77 6b 
          3c 4b 8f cc 73 47 eb a0 f9 d2 4c fc cd c8 87 3a 
        cipherSuite         TLS_RSA_WITH_AES_256_GCM_SHA384
        compressionMethod                   NULL
2 3  0.0024 (0.0000)  S>CV3.3(956)  Handshake
      Certificate
2 4  0.0024 (0.0000)  S>CV3.3(4)  Handshake
      ServerHelloDone
2 5  0.0052 (0.0027)  C>SV3.3(262)  Handshake
      ClientKeyExchange
2 6  0.0052 (0.0000)  C>SV3.3(1)  ChangeCipherSpec
2 7  0.0052 (0.0000)  C>SV3.3(40)  Handshake
2 8  0.0119 (0.0066)  S>CV3.3(1)  ChangeCipherSpec
2 9  0.0119 (0.0000)  S>CV3.3(40)  Handshake
2    0.0203 (0.0084)  C>S  TCP FIN
2    0.0204 (0.0001)  S>C  TCP FIN

Is this the normal behavior? I can't see any errors. This seems not optimal...

Thanks! Rafael

application delivery
BIG-IP
LTM
security

3 Replies

Sort By
  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    May 06, 2018

    Does this occur with Chrome/Firefox/Edge?

     

    What is the client-ssl profile configuration?

     

  • rafaelbn_305907's avatar
    rafaelbn_305907
    Icon for Nimbostratus rankNimbostratus
    May 06, 2018

    Hello Blakely!

    Yes. All three browsers behave the same. I think this could be the self-signed certificate. Since the browser is expecting the user to accept the security exception, it sends the reset to the server. When the client confirms the exception, the browser starts a new connection. Does that make sense to you?

    If I connect from a linux box through "openssl s_client -connect 192.168.1.43:443", the ssldump is perfect!

    Client ssl is as follows:

    ltm profile client-ssl clientssl_lab.local {
    app-service none
    cert lab.local.crt
    cert-key-chain {
        lab.local_lab.local {
            cert lab.local.crt
            chain lab.local.crt
            key lab.local.key
        }
    }
    chain lab.local.crt
    ciphers DEFAULT
    defaults-from clientssl
    inherit-certkeychain false
    key lab.local.key
    passphrase none
    peer-cert-mode require
}

    Thanks! Rafael

  • rafaelbn_305907's avatar
    rafaelbn_305907
    Icon for Nimbostratus rankNimbostratus
    May 07, 2018

    I did a tcpdump and I can see that when I try to connect through a browser (IE11), the browser establishes 4 connections and do 4 client hellos.

     

     

    But when I connect through "openssl s_client -connect 192.168.1.43:443" and do a "GET / HTTP/1.0" I get the same page but only one connection:

     

     

    I uploaded both captures to cloudshark:

     

    Connection from Linux box (only one SSL client hello) - https://www.cloudshark.org/captures/63c678837a25

     

    Connection from IE11 (4 SSL client hellos) - https://www.cloudshark.org/captures/f6924bd9ecaa

     

    Thanks! Rafael