Unknown record type 207: what is it, and why does it cause SSL to fail?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I am having a problem where an iPhone running iOS v9.3.3 is attempting to connect to httpd+openssl on CentOS7 and suddenly failing when this used to work in the past.

The client (iOS) seems to believe the SSL handshake is successful, and so attempts to send some application data. The server (httpd), appears to be offended by this, and returns "unknown record type: 207?. The server then slams the phone down, and the client follows suit directly after.

Some questions:

- What is record type 207?
- Why would openssl believe that record type 207 is not known?

The trace from ssldump is below.

1 1  0.0089 (0.0089)  C>S V3.1(223)  Handshake
      ClientHello
        Version 3.3 
        random[32]=
          57 a4 8d b0 4c 85 18 b6 dd e1 1f 10 5a 41 5e 8b 
          73 5f eb 49 77 6c ee 33 f1 5c 57 a0 c0 d2 95 ab 
        cipher suites
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
        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
        compression methods
                  NULL
1 2  0.0221 (0.0131)  S>C V3.3(93)  Handshake
      ServerHello
        Version 3.3 
        random[32]=
          57 a4 8c 87 8c 6c 8a fc e0 7f 73 64 a9 b2 27 ad 
          6a e8 fa 46 b4 e1 db dd 7d f2 fd 07 e1 e8 1e ed 
        session_id[32]=
          12 7b 6e ad 46 df 9b 20 21 2a 31 e8 b6 cb 4d 75 
          cf ec 2c af 7b 22 49 8d d9 98 1d fb bf de ca e2 
        cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        compressionMethod                   NULL
1 3  0.0221 (0.0000)  S>C V3.3(2790)  Handshake
[snip server certificate]
1 4  0.0221 (0.0000)  S>C  Short record: 589 bytes available (expecting: 592)
1 5  0.0221 (0.0000)  S>C V215.13(0)  unknown record type: 0
1 6  0.1699 (0.1478)  C>S V3.3(953)  Handshake
[snip client certificate]
1 7  0.1700 (0.0000)  C>S V3.3(70)  Handshake
      ClientKeyExchange
Not enough data. Found 64 bytes (expecting 16384)
1 8  0.1700 (0.0000)  C>S V3.3(264)  Handshake
      CertificateVerify
Not enough data. Found 258 bytes (expecting 16384)
1 9  0.1700 (0.0000)  C>S V3.3(1)  ChangeCipherSpec
1 10 0.1700 (0.0000)  C>S V3.3(40)  Handshake
1 11 0.1820 (0.0119)  C>S V3.3(379)  application_data
1 12 0.1829 (0.0008)  S>C V3.1(576)  unknown record type: 207
1    5.1278 (4.9449)  S>C  TCP FIN
1    5.6138 (0.4859)  C>S  TCP FIN

Regards,
Graham
?



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux