What does TLS Handshake Type 174 Mean?

Demystifying TLS Handshake Type 174: An Unofficial Deep Dive

Explore the meaning behind TLS Handshake Type 174, a non-standard and often misunderstood value encountered in network traffic analysis, and learn how to interpret such anomalies.

When analyzing network traffic, especially encrypted communications using TLS/SSL, you might occasionally encounter unusual values that don't seem to fit the standard specifications. One such value that has puzzled many network engineers and security analysts is a TLS Handshake Type of 174. This article delves into what this value typically signifies, why it appears, and how to approach its interpretation.

Understanding TLS Handshake Messages

The Transport Layer Security (TLS) protocol relies on a series of handshake messages to establish a secure connection between a client and a server. These messages are defined by specific types, each with a designated numerical value. For instance, ClientHello is type 1, ServerHello is 2, Certificate is 11, ServerKeyExchange is 12, and Finished is 20. These types are formally defined in RFCs (Request for Comments) that govern the TLS protocol, such as RFC 5246 for TLS 1.2 or RFC 8446 for TLS 1.3.

sequenceDiagram
    participant Client
    participant Server

    Client->>Server: ClientHello (Type 1)
    Server->>Client: ServerHello (Type 2)
    Server->>Client: Certificate (Type 11)
    Server->>Client: ServerKeyExchange (Type 12)
    Server->>Client: ServerHelloDone (Type 14)
    Client->>Server: ClientKeyExchange (Type 16)
    Client->>Server: ChangeCipherSpec (Type 20)
    Client->>Server: Encrypted Handshake Message (Finished) (Type 20)
    Server->>Client: ChangeCipherSpec (Type 20)
    Server->>Client: Encrypted Handshake Message (Finished) (Type 20)
    Client-->>Server: Application Data (Encrypted)
    Server-->>Client: Application Data (Encrypted)

Simplified TLS 1.2 Handshake Flow with Standard Message Types

The Enigma of Handshake Type 174

The crucial point about 174 is that it is not a standard, officially defined TLS handshake message type according to any published RFC. The official range for TLS handshake message types is typically much smaller, usually from 0 to 255, but only a subset of these are assigned. When a packet capture or network analysis tool reports a handshake type of 174, it almost invariably points to one of the following scenarios:

1. Protocol Misinterpretation: The most common reason is that the network analysis tool (e.g., Wireshark, tcpdump) is misinterpreting the packet. This can happen if the tool's dissector for TLS is outdated, corrupted, or if the packet itself is malformed in a way that leads to incorrect parsing.
2. Non-TLS Protocol Encapsulation: The traffic might not be TLS at all, but rather another protocol that happens to use a similar header structure, leading the dissector to incorrectly identify it as TLS. This is less common for 174 specifically, but a general possibility for unknown types.
3. Proprietary or Custom Protocol: In some rare cases, a vendor might implement a proprietary protocol that mimics TLS or uses a custom extension that is not publicly documented. However, assigning a completely undefined handshake type like 174 to a standard TLS field would be highly unusual and non-compliant.
4. Data Corruption or Packet Loss: Network issues like packet corruption or fragmentation can lead to incorrect parsing of headers, resulting in seemingly random or undefined values.

Investigating and Troubleshooting

When you encounter a TLS Handshake Type 174, here's a systematic approach to investigate:

1. Update Your Tools: Ensure your network analysis software (e.g., Wireshark) is up-to-date. Dissector updates often fix parsing issues for various protocols.
2. Examine Raw Packet Data: Look at the raw hexadecimal data of the packet. The handshake type is usually a single byte. If it's truly 0xAE (174 in decimal), try to manually parse the subsequent bytes based on known TLS handshake message structures. This can help identify if it's a malformed standard message or something entirely different.
3. Check for Fragmentation: If the packet is fragmented, reassemble it if possible. Fragmentation can sometimes lead to dissector confusion.
4. Analyze the Full Flow: Don't just look at the single packet. Examine the entire TCP stream. Does the communication establish a successful connection? Are other TLS messages present and correctly identified? If the connection proceeds normally despite the 174, it's highly likely a parsing error.
5. Consider the Application: What application is generating this traffic? Some applications might use non-standard implementations or proxies that could interfere with standard TLS dissectors.
6. Search Online Forums: A value like 174 might have been encountered by others. Searching security forums or Wireshark mailing lists can sometimes reveal specific scenarios or known bugs related to its appearance.

Frame 123: 150 bytes on wire (1200 bits), 150 bytes captured (1200 bits)
Ethernet II, Src: Vmware_00:00:00 (00:00:00:00:00:00), Dst: Vmware_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 192.168.1.100, Dst: 192.168.1.1
Transmission Control Protocol, Src Port: 54321, Dst Port: 443, Seq: 1, Ack: 1, Len: 96
Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Unknown (Type 174)
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 91
        Handshake Protocol: Unknown (Type 174)
            Handshake Type: Unknown (174)
            Length: 87
            [... Raw Handshake Data ...]

Example Wireshark output showing an 'Unknown (Type 174)' TLS handshake message.