This is a static archive of our old Q&A Site. Please post any new questions and answers at

TLSV1 “Ignored Unknown Record”


A wireshark trace of a TLS mailflow has packets with "Ignored Unknown Record" and I can't seem to find a solution to display them.

Allow Subdissector to Reassemble TCP Streams as suggested by Laura's is already checked.

What else may cause Ignored Unknown Record ?

asked 04 Dec '13, 11:54

net_tech's gravatar image

accept rate: 13%

2 Answers:


You probably have a SMTP handshake happening before the TLS negotiation. See . So, if you do the "Decode as SSL" on all packets wireshark will treat those as unknown TLS.

> S: 220 ESMTP Server  
> C: EHLO   S:
> Hello
>   S: 250-AUTH
> STARTTLS   C: STARTTLS   S: 220 Ready
> to start TLS
>     ... TLS negotiation proceeds. 
>      Further commands protected by TLS layer ...   C: EHLO
> S: Hello
>   S: 250 AUTH
> PLAIN dGVzdAB0ZXN0ADEyMzQ=   S: 235
> 2.7.0 Authentication successful

answered 04 Dec '13, 21:20

mrEEde's gravatar image

accept rate: 20%

Good idea!

(05 Dec '13, 02:17) Kurt Knochner ♦

while you are right regarding the "Decode as" part (Wireshark indeed shows the SMTP traffic as "Ignored Unknown Record", it is not necessary to run "Decode as", because Wireshark detects the STARTTLS command and shows the following frames as TLS.

So I wonder why the OP should have done "Decode as" !?! Let's see if @net_tech ever responds to this....

(05 Dec '13, 04:26) Kurt Knochner ♦


What else may cause Ignored Unknown Record ?

Maybe your mail server (deducted from the phrase 'mailflow') uses a TLS record type that is unknown to Wireshark (in general, or the version you are using).

From the code: packet-ssl.c

       / TLS 1.0/1.1 just ignores unknown records - RFC 2246 chapter 6. The TLS Record Protocol /
        if ((conv_version==SSL_VER_TLS || conv_version==SSL_VER_TLSv1DOT1 || *conv_version==SSL_VER_TLSv1DOT2) &&
            (available_bytes >=1 ) && !ssl_is_valid_content_type(tvb_get_guint8(tvb, offset))) {
            proto_tree_add_text(tree, tvb, offset, available_bytes, "Ignored Unknown Record");

Then from RFC2246 chapter 6

   Any new record types should
   allocate type values immediately beyond the ContentType values for
   the four record types described here (see Appendix A.2). If a TLS
   implementation receives a record type it does not understand, it
   should just ignore it.

Then from packet-ssl-utils.c

ssl_is_valid_content_type(guint8 type)
    if ((type >= 0x14) && (type <= 0x18))
        return 1;
return 0;</code></pre><p>So, Wireshark will only be able to 'understand' types between 0x14 and 0x18. What do you see in your capture file?</p><p>Regards<br />


answered 04 Dec ‘13, 14:55

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

edited 04 Dec ‘13, 15:04

Got a little problem here. As I was working with the trace, instead of saving the file I exported it as text from Wireshark 1.4 and could not import it back. I can open the exported file in 1.10, but I think some of the metadata was lost during the export. To make the problem worse, the issue was corrected at the receiver’s end and I can’t recapture questionable traffic.

I did however find several references to TLS & encryption issues caused by watchguard firebox firewall, which is exactly what is used at the other side of the wire

(05 Dec ‘13, 06:05) net_tech

Upgraded to Wireshark 1.10.3 but I still see “Ignored Unknown Records” in other SMTP connections.

If I do “Decode as SSL” or simply “Follow SSL Stream” as mrEEde suggested I get decrypted SMTP communication. (private key is added to SSL protocol)

(05 Dec ‘13, 06:32) net_tech


is content type stored in tcp.flags field ?

(05 Dec ‘13, 06:39) net_tech

Upgraded to Wireshark 1.10.3 but I still see “Ignored Unknown Records” in other SMTP connections.

can you post a sample capture (without key) on google drive, dropbox, or

is content type stored in tcp.flags field ?

no, in ssl.record.content_type

(05 Dec ‘13, 06:55) Kurt Knochner ♦

can’t post a capture, but can share a screenshot

alt text

(05 Dec ‘13, 07:05) net_tech

I think I figured it out. the packet shown below becomes “Ignored Unknown Records” when private key is added to the SSL protocol

alt text

(05 Dec ‘13, 07:20) net_tech

well, is that with or without “Decode as …” ? Please check

Analyze -> Decode as -> Show current

If there is any entry for port 25, delete it and test again.

(05 Dec ‘13, 07:37) Kurt Knochner ♦

Not sure if I explained what happens clear enough. If I go to Edit -> Preferences -> Protocols -> SSL and remove my private key from the RSA key list, frame 5578 is displayed as shown below.

alt text

If I go back and add the private key and specify IP, TCP port and protocol, the same frame changes it’s display to the Ignored Unknown Record.

alt text

(05 Dec ‘13, 08:08) net_tech

ah, so you only see that message when you are decrypting the TLS data in the SMTP connection? There is no “Decode as” configured, right?

(05 Dec ‘13, 08:14) Kurt Knochner ♦

correct, no “Decode as” configured

(05 Dec ‘13, 08:20) net_tech

O.K. could be a ‘bug’ with the TLS (SMTP) decryption routine, as Frame #5578 is dissected as SMTP traffic ‘before’ you decrypt it.

(05 Dec ‘13, 08:29) Kurt Knochner ♦

I can confirm the behavior @net_tech found. As soon as a key is used to decrypt ‘STARTTLS traffic’ the former SMTP frames will be shown as “Ignored Unknown Record”. Looks like a bug. Not sure if that is easy to fix….

@net_tech: please file a bug report at

Hint: If a supplied answer resolves your question can you please “accept” it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(05 Dec ‘13, 09:38) Kurt Knochner ♦

submitted as bug # 9515

(05 Dec ‘13, 10:37) net_tech
showing 5 of 13 show 8 more comments