Wireshark doesn't recognize packet as TLS ClientHello

Question

I'm trying to analyze a TLS library for Java (not Bouncy Castle). For some reason, Wireshark refuses to recognize a ClientHello fragment as such. Here is a hex dump of the TCP packet. I have broken it up into it's component parts to make it a bit easier to follow.

TCP stuff
020000004502008a000040004006f9ce0aa5001e5db8d822e28d01bbf3b9a9ab8c64a4fe8018081070fa00000101080a4e4e5d5845aa256f

16 TLS handshake record
0301 TLS v 1.0
0052 Fragment length 82 bytes
01 ClientHello message
00004e Message length 78 bytes
0303 TLS v 1.2
Client random
3c88c697bf2b559cc032faff7caccb17475ae76f36ededf279a9d1b9950e7367
00 Session ID length
0024 Cipher suite length 36 bytes 18 cipher suites
1301 1302 1303 c02b c02f cca9 ccaa c02c c030 c00a c009 c013 c014 009c 009d 002f 0035 000a
01 Compression methods length
00 Compression method null
0000 Extensions length

I'm at a loss to understand why Wireshark and several websites don't recognize this as a valid handshake record. Any help is appreciated.

EDIT:

I re-ran the capture to show how Wireshark interprets the network header.

The raw packet

0000   0c ea c9 75 61 30 3c 22 fb 01 07 f3 08 00 45 00
0010   00 8a 00 00 40 00 40 06 42 23 c0 a8 01 c8 5d b8
0020   d8 22 e9 3b 01 bb ee e9 99 55 53 56 a2 a8 80 18
0030   08 0a dc d0 00 00 01 01 08 0a 4e d6 03 2b db 4f
0040   3f fb 16 03 01 00 52 01 00 00 4e 03 03 8a 80 b9
0050   8c 73 ee 40 30 ef 65 1d 8c 51 d2 39 09 34 17 79
0060   d1 af e1 63 96 1a ac b4 ad 96 03 dd 7a 00 00 24
0070   13 01 13 02 13 03 c0 2b c0 2f cc a9 cc aa c0 2c
0080   c0 30 c0 0a c0 09 c0 13 c0 14 00 9c 00 9d 00 2f
0090   00 35 00 0a 01 00 00 00

The Wireshark interpretation

Frame 3616: 152 bytes on wire (1216 bits), 152 bytes captured (1216 bits) on interface en0, id 0
    Interface id: 0 (en0)
    Encapsulation type: Ethernet (1)
    Arrival Time: Nov  3, 2020 09:03:23.957190000 EST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1604412203.957190000 seconds
    [Time delta from previous captured frame: 0.004793000 seconds]
    [Time delta from previous displayed frame: 0.011314000 seconds]
    [Time since reference or first frame: 49.409611000 seconds]
    Frame Number: 3616
    Frame Length: 152 bytes (1216 bits)
    Capture Length: 152 bytes (1216 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: Apple_01:07:f3 (3c:22:fb:01:07:f3), Dst: ARRISGro_75:61:30 (0c:ea:c9:75:61:30)
    Destination: ARRISGro_75:61:30 (0c:ea:c9:75:61:30)
    Source: Apple_01:07:f3 (3c:22:fb:01:07:f3)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.200, Dst: 93.184.216.34
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 138
    Identification: 0x0000 (0)
    Flags: 0x40, Don't fragment
    Fragment Offset: 0
    Time to Live: 64
    Protocol: TCP (6)
    Header Checksum: 0x4223 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.1.200
    Destination Address: 93.184.216.34
Transmission Control Protocol, Src Port: 59707, Dst Port: 443, Seq: 1, Ack: 1, Len: 86
    Source Port: 59707
    Destination Port: 443
    [Stream index: 18]
    [TCP Segment Len: 86]
    Sequence Number: 1    (relative sequence number)
    Sequence Number (raw): 4008286549
    [Next Sequence Number: 87    (relative sequence number)]
    Acknowledgment Number: 1    (relative ack number)
    Acknowledgment number (raw): 1398186664
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x018 (PSH, ACK)
    Window: 2058
    [Calculated window size: 131712]
    [Window size scaling factor: 64]
    Checksum: 0xdcd0 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
    [SEQ/ACK analysis]
    [Timestamps]
    TCP payload (86 bytes)
    TCP segment data (86 bytes)

What you label 'TCP stuff' appears to actually be some very simple (or pseudo) link (4 bytes), IPv4 (20 bytes) _and_ TCP (32 bytes). And the TCP header shows it going to port 443, which Wireshark does know is TLS-was-SSL, so IF it recognizes this as a frame at all, it should decode it as TLS. Was it captured _by_ Wireshark, or something that uses a file format compatible with Wireshark? Was it on an actual network link, or something else like a VPN, tunnel, bridge or virtual network? Does Wireshark show the IP and TCP levels correctly, incorrectly, or not at all? — dave_thompson_085, Nov 03 '20 at 06:32
I edited the question to include the wireshark interpretation for the whole packet. — SteveB, Nov 03 '20 at 14:48
AH! Your hexdump makes it (much) easier to see -- YOUR LENGTHS ARE OFF. You have the record/fragment length as 0052 when the data is actually 0x51 bytes, and the message length as 00004E when it's actually 0x4D. Whatever library that is is apparently defective. Also, I was in a bit of a hurry before and didn't say but: sending 1.2 hello without sigalgs, although legal, is a bad idea; not having SNI in today's Internet probably won't work; not having either of the RFC5746 options (extension or SCSV) almost certainly won't work; offering EC suites without supported_curves at least — dave_thompson_085, Nov 04 '20 at 09:37
and probably point_formats is bad; and offering TLS1.3 suites without using the required 1.3 extensions (supported_versions, supported_groups, key_share) is utterly useless. — dave_thompson_085, Nov 04 '20 at 09:38
Thanks, Dave! The extensions configuration is my fault. Or more accurately, I hadn't done it yet. I was just trying to get Wireshark to show me the handshake. The message lengths thing is very concerning, though. I appreciate the help. — SteveB, Nov 04 '20 at 22:50

Wireshark doesn't recognize packet as TLS ClientHello

0 Answers0