mqtt was identified as TLS
echoechoin opened this issue · 6 comments
-----------------------------------------------------------
* NOTE: This is demo app to show *some* nDPI features.
* In this demo we have implemented only some basic features
* just to show you what you can do with the library. Feel
* free to extend it and send us the patches for inclusion
------------------------------------------------------------
Using nDPI (4.8.0-4333-467c27ce) [1 thread(s)]
Using libgcrypt version 1.8.6internal
Reading packets from pcap file /home/echo/work/108_sample_result/mqtt.pcap...
Running thread 0...
nDPI Memory statistics:
nDPI Memory (once): 37.20 KB
Flow Memory (per flow): 944 B
Actual Memory: 7.83 MB
Peak Memory: 7.83 MB
Setup Time: 38 msec
Packet Processing Time: 0 msec
Traffic statistics:
Ethernet bytes: 695 (includes ethernet CRC/IFC/trailer)
Discarded bytes: 0
IP packets: 1 of 1 packets total
IP bytes: 671 (avg pkt size 671 bytes)
Unique flows: 1
TCP Packets: 1
UDP Packets: 0
VLAN Packets: 0
MPLS Packets: 0
PPPoE Packets: 0
Fragmented Packets: 0
Max Packet size: 637
Packet Len < 64: 0
Packet Len 64-128: 0
Packet Len 128-256: 0
Packet Len 256-1024: 1
Packet Len 1024-1500: 0
Packet Len > 1500: 0
nDPI throughput: 1.96 K pps / 10.42 Mb/sec
Analysis begin: 11/Apr/2024 14:24:59
Analysis end: 11/Apr/2024 14:24:59
Traffic throughput: 0.00 pps / 0 b/sec
Traffic duration: 0.000 sec
Guessed flow protos: 1
DPI Packets (TCP): 1 (1.00 pkts/flow)
Confidence: DPI 1 (flows)
Detected protocols:
TLS packets: 1 bytes: 671 flows: 1
Protocol statistics:
Safe 671 bytes
Risk stats [found 1 (100.0 %) flows with risks]:
Known Proto on Non Std Port 1 [50.0 %]
Unidirectional Traffic 1 [50.0 %]
NOTE: as one flow can have multiple risks set, the sum of the
last column can exceed the number of flows with risks.
and this SNMP pcap is identified as TLS:
snmp.tar.gz
Without using Wireshark, I would say that such things may happen for malformed packets.
nDPI does packet dissection different then Wireshark and thus the results (especially for malformed packets) may vary.
Is that packet a forged / fuzzed one?
how about the smnp pcap files? They look like right packets.
Please try running ndpiReader again with -d -v2 as additional arguments and paste the output here.
In the first trace, there is (only) a valid Client Hello to m.etax.chinatax.gov.cn, so the classification returned from nDPI seems correct.
In the second trace, the first pkt is a valid Client Hello, but the response from the server is a SMTP banner, in cleartext. This is completely non standard; if this is real traffic I would like to see the next reply from the client: I bet it is some kind of TCP RST or TLS error.
You can see this trace as an TLS attempt connection with the server replying with random data, i.e. the TLS handshake fails. No sure what nDPI should/could do differently here...
Thanks! Our device is filled with lots of error messages. That is a big problem.