- TCP fingerprint
- JA4 fingepriint
- TLS SHA1 certificate (if present), or JA3S fingerprint (is SHA1 is missing)
By default the fingerprint uses the client and server fingerprints (format 0)
and combines them. However you can chnge it format (eg. use only the client info,
format 1) with
--cfg NULL,metadata.ndpi_fingerprint_format,X
where X is the fingerprint format.
By default nDPI fingerprint is enabled but you can enable/disble it as follows
--cfg NULL,metadata.ndpi_fingerprint,0
The idea is to remove the limitation of only two protocols ("master" and
"app") in the flow classifcation.
This is quite handy expecially for STUN flows and, in general, for any
flows where there is some kind of transitionf from a cleartext protocol
to TLS: HTTP_PROXY -> TLS/Youtube; SMTP -> SMTPS (via STARTTLS msg).
In the vast majority of the cases, the protocol stack is simply
Master/Application.
Examples of real stacks (from the unit tests) different from the standard
"master/app":
* "STUN.WhatsAppCall.SRTP": a WA call
* "STUN.DTLS.GoogleCall": a Meet call
* "Telegram.STUN.DTLS.TelegramVoip": a Telegram call
* "SMTP.SMTPS.Google": a SMTP connection to Google server started in
cleartext and updated to TLS
* "HTTP.Google.ntop": a HTTP connection to a Google domain (match via
"Host" header) and to a ntop server (match via "Server" header)
The logic to create the stack is still a bit coarse: we have a decade of
code try to push everything in only ywo protocols... Therefore, the
content of the stack is still **highly experimental** and might change
in the next future; do you have any suggestions?
It is quite likely that the legacy fields "master_protocol" and
"app_protocol" will be there for a long time.
Add some helper to use the stack:
```
ndpi_stack_get_upper_proto();
ndpi_stack_get_lower_proto();
bool ndpi_stack_contains(struct ndpi_proto_stack *s, u_int16_t proto_id);
bool ndpi_stack_is_tls_like(struct ndpi_proto_stack *s);
bool ndpi_stack_is_http_like(struct ndpi_proto_stack *s);
```
Be sure new stack logic is compatible with legacy code:
```
assert(ndpi_stack_get_upper_proto(&flow->detected_protocol.protocol_stack) ==
ndpi_get_upper_proto(flow->detected_protocol));
assert(ndpi_stack_get_lower_proto(&flow->detected_protocol.protocol_stack) ==
ndpi_get_lower_proto(flow->detected_protocol));
```
This function is always called once for every flow, as last code
processing the flow itself.
As a first usage example, check here if the flow is unidirectional
(instead of checking it at every packets)
This cache was added in b6b4967aa, when there was no real Zoom support.
With 63f349319, a proper identification of multimedia stream has been
added, making this cache quite useless: any improvements on Zoom
classification should be properly done in Zoom dissector.
Tested for some months with a few 10Gbits links of residential traffic: the
cache pretty much never returned a valid hit.
* Add Omron FINS protocol dissector
* Add a kludge to avoid invalid FINS over UDP detection as SkypeTeams and RTP
* Update unit test results
* Update protocols.rst
* Remove dummy flows from fins.pcap
* Add HART-IP protocol dissector
* Update docs
* Update protocols.rst
* Reuse free proto id and re-run tests
* docs: move HART-IP to top of list
---------
Co-authored-by: 0xA50C1A1 <mage.wizard88@gmail.com>
* Add IEEE 1588-2008 (PTPv2) dissector
PTPv2 is a time synchronization protocol in computer networks, similar to NTP.
* Add default protocol ports
* Update default test result for PTPv2
* Update copyright
---------
Co-authored-by: 0xA50C1A1 <mage.wizard88@gmail.com>
Regardless of the name, the removed trace doesn't contain meaningful
Hangout traffic.
Remove last piece of sub-classifiction based only on ip addresses.
Try avoiding false positives: look for 3 RTP packets before classifing
the flow as such.
Add a generic function `is_rtp_or_rtcp()` to identify RTP/RTCP packets also
in other dissectors (see 3608ab01b commit message for an example)
For a lot of protocols, reduce the number of packets after which the
protocols dissector gives up.
The values are quite arbitary, tring to not impact on classification
Extend internal unit tests to handle multiple configurations.
As some examples, add tests about:
* disabling some protocols
* disabling Ookla aggressiveness
Every configurations data is stored in a dedicated directory under
`tests\cfgs`
2023-04-06 11:30:36 +02:00
Renamed from tests/result/radius_false_positive.pcapng.out (Browse further)
