Revision history [back]

When implementations fail during the TLS handshake, they typically do either:

• Forcefully the TCP connection. This can be found with the display filter tcp.flags.reset==1
• Send an unencrypted Alert message. This can be found with the display filter tls.alert_message.level

Combining the two:

tcp.flags.reset==1 or tls.alert_message.level

Note that normal TLS sessions may also use the TCP RST (reset) flag to tear down a connection to close down a successful session. If you see Application Data packets in the same TCP stream, then this would indicate that.

When implementations fail during the TLS handshake, they typically do either:

• Forcefully the TCP connection. This can be found with the display filter tcp.flags.reset==1
• Send an unencrypted Alert message. This can be found with the display filter tls.alert_message.level

Combining the two:

tcp.flags.reset==1 or tls.alert_message.level

Note that normal TLS sessions may also use the TCP RST (reset) flag to tear down a connection to close down a successful session. If you see Application Data packets in the same TCP stream, then this would indicate that.

When implementations fail during the TLS handshake, they typically do either:

• Forcefully close the TCP connection. This can be found with the display filter tcp.flags.reset==1
• Send an unencrypted Alert message. This can be found with the display filter tls.alert_message.level

Combining the two:

tcp.flags.reset==1 or tls.alert_message.level

Note that normal TLS sessions may also use the TCP RST (reset) flag to tear down a connection to close down a successful session. If you see Application Data packets in the same TCP stream, then this would indicate that.

If you are using Wireshark 2.6 or older, note that the filter is named ssl.alert_message.level instead.