diff options
| author | Ivan Nardi <12729895+IvanNardi@users.noreply.github.com> | 2022-09-20 22:24:47 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-09-20 22:24:47 +0200 |
| commit | a7c2734b387f6817088593f7c4e78d01dd6e0b74 (patch) | |
| tree | b112686c6ff07ae8210567f6079f415e8fb7ff2d /tests/result/tls_missing_ch_frag.pcap.out | |
| parent | 174cd739dbb1358ab012c4779e42e0221bef835c (diff) | |
Remove classification "by-ip" from protocol stack (#1743)
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
Diffstat (limited to 'tests/result/tls_missing_ch_frag.pcap.out')
| -rw-r--r-- | tests/result/tls_missing_ch_frag.pcap.out | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/tests/result/tls_missing_ch_frag.pcap.out b/tests/result/tls_missing_ch_frag.pcap.out index 7ca511a2d..2ee38677f 100644 --- a/tests/result/tls_missing_ch_frag.pcap.out +++ b/tests/result/tls_missing_ch_frag.pcap.out @@ -25,4 +25,4 @@ JA3 Host Stats: IP Address # JA3C - 1 TCP 10.10.10.1:443 <-> 192.168.0.1:33063 [proto: 91/TLS][Encrypted][Confidence: DPI][cat: Web/5][6 pkts/6525 bytes <-> 8 pkts/3557 bytes][Goodput ratio: 94/85][0.38 sec][bytes ratio: 0.294 (Upload)][IAT c2s/s2c min/avg/max/stddev: 0/0 40/13 161/59 70/23][Pkt Len c2s/s2c min/avg/max/stddev: 66/66 1088/445 2023/1090 747/434][TLSv1.3][JA3S: 907bf3ecef1c987c889946b737b43de8][Cipher: TLS_AES_256_GCM_SHA384][Plen Bins: 0,0,11,0,0,11,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,11,0,0,0,0,0,0,0,0,0,22,0,0,0,0,0,0,0,0,0,0,33,0,0,0,11] + 1 TCP 10.10.10.1:443 <-> 192.168.0.1:33063 [proto: 91/TLS][IP: 0/Unknown][Encrypted][Confidence: DPI][cat: Web/5][6 pkts/6525 bytes <-> 8 pkts/3557 bytes][Goodput ratio: 94/85][0.38 sec][bytes ratio: 0.294 (Upload)][IAT c2s/s2c min/avg/max/stddev: 0/0 40/13 161/59 70/23][Pkt Len c2s/s2c min/avg/max/stddev: 66/66 1088/445 2023/1090 747/434][TLSv1.3][JA3S: 907bf3ecef1c987c889946b737b43de8][Cipher: TLS_AES_256_GCM_SHA384][Plen Bins: 0,0,11,0,0,11,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,11,0,0,0,0,0,0,0,0,0,22,0,0,0,0,0,0,0,0,0,0,33,0,0,0,11] |