search

cisco / joy

A package for capturing and analyzing network flow data and intraflow data, for network research, forensics, and security monitoring.
Other
1.31k stars 329 forks source link

Incorrect TLS handshake types and TLS content types when generating TLS session metadata #284

Open wtoxin opened 5 years ago

wtoxin commented 5 years ago

Problems encountered when generating "tls" information for TLS flows, specifically in the "srlt" sequence.

  1. After the Client Change Cipher Spec message in a TLS flow, the next handshake message which is encypted is incorrectly annotated as _"tp":22, "hstypes":[0,0]. As I think, the _"hstypes" should be none here since this message is encrypted and cannot be identified.

image

  1. There seems to be some failures in generating correct TLS content types within the "srlt" sequence. Here are some examples (the numbers without brackets are TLS content types, thoses in brackets are specific TLS handshake types):
    • [[1], [2], 22, [16], 20, 22, 23, 47, 21]
    • [[1], [2], 20, 22, 20, 22, 23, 23, 23, 23, 23, 23, 116, 199, 36, 31, 140, 23, 23, 253, 23, 75, 54, 21]
    • [[1], [2], [11], [12], [14], [16], 20, 22, 23, 23, [4], 20, 22, 23, 23, 23, 23, 23, 0, 23, 23, 23, 23, 23, 34, 150, 3, 140, 67] We can see that sometimes the content type numbers are beyond the scope of 20, 21, 22 and 23, which is nonsense. The correct type numbers are actually 23 after checking the original pcap files (not all are verified).