mirror of
https://github.com/vel21ripn/nDPI.git
synced 2026-05-04 09:50:16 +00:00
Basically: * "classification by-ip" (i.e. `flow->guessed_protocol_id_by_ip` is NEVER returned in the protocol stack (i.e. `flow->detected_protocol_stack[]`); * if the application is interested into such information, it can access `ndpi_protocol->protocol_by_ip` itself. There are mainly 4 points in the code that set the "classification by-ip" in the protocol stack: the generic `ndpi_set_detected_protocol()`/ `ndpi_detection_giveup()` functions and the HTTP/STUN dissectors. In the unit tests output, a print about `ndpi_protocol->protocol_by_ip` has been added for each flow: the huge diff of this commit is mainly due to that. Strictly speaking, this change is NOT an API/ABI breakage, but there are important differences in the classification results. For examples: * TLS flows without the initial handshake (or without a matching SNI/certificate) are simply classified as `TLS`; * similar for HTTP or QUIC flows; * DNS flows without a matching request domain are simply classified as `DNS`; we don't have `DNS/Google` anymore just because the server is 8.8.8.8 (that was an outrageous behaviour...); * flows previusoly classified only "by-ip" are now classified as `NDPI_PROTOCOL_UNKNOWN`. See #1425 for other examples of why adding the "classification by-ip" in the protocol stack is a bad idea. Please, note that IPV6 is not supported :( (long standing issue in nDPI) i.e. `ndpi_protocol->protocol_by_ip` wil be always `NDPI_PROTOCOL_UNKNOWN` for IPv6 flows. Define `NDPI_CONFIDENCE_MATCH_BY_IP` has been removed. Close #1687
29 lines
2 KiB
Text
29 lines
2 KiB
Text
Guessed flow protos: 0
|
|
|
|
DPI Packets (TCP): 8 (8.00 pkts/flow)
|
|
Confidence DPI : 1 (flows)
|
|
Num dissector calls: 1 (1.00 diss/flow)
|
|
LRU cache ookla: 0/0/0 (insert/search/found)
|
|
LRU cache bittorrent: 0/0/0 (insert/search/found)
|
|
LRU cache zoom: 0/0/0 (insert/search/found)
|
|
LRU cache stun: 0/0/0 (insert/search/found)
|
|
LRU cache tls_cert: 0/0/0 (insert/search/found)
|
|
LRU cache mining: 0/0/0 (insert/search/found)
|
|
LRU cache msteams: 0/0/0 (insert/search/found)
|
|
Automa host: 1/1 (search/found)
|
|
Automa domain: 1/0 (search/found)
|
|
Automa tls cert: 0/0 (search/found)
|
|
Automa risk mask: 0/0 (search/found)
|
|
Automa common alpns: 7/7 (search/found)
|
|
Patricia risk mask: 2/0 (search/found)
|
|
Patricia risk: 0/0 (search/found)
|
|
Patricia protocols: 2/0 (search/found)
|
|
|
|
Salesforce 15 5205 1
|
|
|
|
JA3 Host Stats:
|
|
IP Address # JA3C
|
|
1 192.168.1.178 1
|
|
|
|
|
|
1 TCP 192.168.1.178:54399 <-> 85.222.142.6:443 [proto: 91.266/TLS.Salesforce][IP: 0/Unknown][Encrypted][Confidence: DPI][cat: Cloud/13][8 pkts/1150 bytes <-> 7 pkts/4055 bytes][Goodput ratio: 53/88][0.15 sec][Hostname/SNI: help.salesforce.com][ALPN: h2;h2-16;h2-15;h2-14;spdy/3.1;spdy/3;http/1.1][bytes ratio: -0.558 (Download)][IAT c2s/s2c min/avg/max/stddev: 0/0 13/5 28/25 13/10][Pkt Len c2s/s2c min/avg/max/stddev: 66/66 144/579 583/1506 169/616][TLSv1.2][JA3C: 7570245c781d7d7a68e31419177e728d][ServerNames: support.salesforce.com,help.salesforce.com][JA3S: 263c859c5391203d774bc0599793d915][Issuer: C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1][Subject: C=US, ST=California, L=San Francisco, O=salesforce.com, inc., CN=support.salesforce.com][Certificate SHA-1: 69:0B:02:F6:58:63:79:69:21:33:61:1A:5C:3D:6A:BD:FC:55:0C:6F][Safari][Validity: 2021-06-07 00:00:00 - 2022-06-06 23:59:59][Cipher: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384][Plen Bins: 0,14,28,0,0,0,0,0,0,0,0,0,0,0,0,0,14,0,14,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,28,0,0]
|