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

tshark -Tfields, identify SSL record types accurately

0

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    127.0.0.1 -> 127.0.0.1    SSLv2 171 Client Hello
  6   0.002160    127.0.0.1 -> 127.0.0.1    SSLv3 995 Server Hello, Certificate,
                                                      Server Hello Done
  8   2.808933    127.0.0.1 -> 127.0.0.1    SSLv3 278 Client Key Exchange,
                                                      Change Cipher Spec,
                                                      Encrypted Handshake Message
  9   2.822770    127.0.0.1 -> 127.0.0.1    SSLv3 141 Change Cipher Spec,
                                                      Encrypted Handshake Message
 11   2.833071    127.0.0.1 -> 127.0.0.1    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
4::1
6:22.22.22:2.11.14
8:22.20.22:16
9:20.22:
11:23:

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

Zack
26●3●3●7
accept rate: 0%

edited 05 May '13, 20:15

One Answer:

1

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.

answered 06 May '13, 01:04

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245
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 Listener.new("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 Listener.new("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