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

I'm using tshark -Tfields to print a packet trace in a machine-readable format, and one of the things I need to extract is the SSL record type for each record in the packet, if the packet contains SSL records. If I print the ssl.record.content_type and ssl.handshake.type fields, they do not seem to be consistent with each other: specifically, for this packet trace

$ tshark -r https_snakeoil.cap -T text | grep SSL | head -5
  4   0.000158 ->    SSLv2 171 Client Hello
  6   0.002160 ->    SSLv3 995 Server Hello, Certificate,
                                                      Server Hello Done
  8   2.808933 ->    SSLv3 278 Client Key Exchange,
                                                      Change Cipher Spec,
                                                      Encrypted Handshake Message
  9   2.822770 ->    SSLv3 141 Change Cipher Spec,
                                                      Encrypted Handshake Message
 11   2.833071 ->    SSLv3 503 Application Data

I get these record and handshake types:

$ tshark -r https_snakeoil.cap -T fields -E separator=: -E accumulator=. \
         -e frame.number -e ssl.record.content_type -e ssl.handshake.type |
    grep -v '::$' | head -5

Problem 1: packet 4 has handshake type 1 but no record type. WTF?
Problem 2: packets 8 and 9 report no handshake type for one of the handshake records. Presumably this is because that handshake record is encrypted. This is a problem because in principle I don't know which one it is (i.e. that 16 in column 3 of packet 8 could go with either of the 22s in column 2). I can assume that the missing values are for 22s following a 20 (that is, ChangeCipherSpec, which turns encryption on) but I suspect this is likely to be unreliable in practice. There doesn't seem to be any way to force aggregated field values to have consistent vector lengths (e.g. 8:22.20.22:16.. would be unambigously parseable). Is there any alternative?

asked 05 May '13, 20:14

Zack's gravatar image

accept rate: 0%

edited 05 May '13, 20:15

Problem 1 is caused by the fact that the client initiated the SSL session with a SSL version 2 client hello. In SSLv2, the SSL records did not have a record type. Do you still see SSLv2 client hello's in your production network?

Problem 2 is indeed caused by the fact that the second SSL handshake message in the packet is encrypted. There is currently no way to correlate multiple occurrences of multiple fields with the "-T fields" output. This cannot be solved in generic way because of the way the "-E fields" option interacts with the dissection data. For SSL handshake messages, this could be solved to add a ssl.handshake.type field for encrypted handshake messages too with a specific code.

You could also use LUA or MATE to link the values together. Or use "-T pdml" to create XML output in which the whole tree is hierarchically printed.

permanent link

answered 06 May '13, 01:04

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

Re SSLv2 client hello, this is probably not an issue for real captures; I just didn't realize that the example HTTPS capture on the wireshark wiki was that old. I'll look into Lua; I already was going to need a postprocessing script, so that might solve two problems at once.

(06 May '13, 08:47) Zack

On further investigation, Lua appears to have the same correlation problem: a"ip") tap that uses extractors to query ssl.record.content_type and ssl.handshake.type will get arrays of length 3 and 1, respectively, for the troublesome packet 8, with no indication of the correlation. A"ssl") tap is only called once, for the first SSL record in the packet. So now I'm stumped again.

(06 May '13, 16:14) Zack
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 05 May '13, 20:14

question was seen: 3,932 times

last updated: 06 May '13, 16:14

p​o​w​e​r​e​d by O​S​Q​A