| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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));
```
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix JA4 ALPN fingerprint to use first and last characters
According to the JA4 specification (line 2139), the ALPN field should
contain the first and last characters of the first ALPN extension value.
Currently, nDPI uses the first and second characters (alpn[0] and alpn[1]),
which produces incorrect fingerprints that don't match other JA4
implementations like Wireshark.
For example, with ALPN 'http/1.1':
- Current (incorrect): 'ht' (first + second char)
- Fixed (correct): 'h1' (first + last char)
This change ensures nDPI's JA4 implementation conforms to the official
specification and maintains interoperability with other JA4 tools.
Fixes: Incorrect JA4 ALPN fingerprint generation
* Fix JA4 ALPN implementation to correctly parse first ALPN protocol
The previous fix attempted to use strlen(ja->client.alpn)-1 but this was
insufficient because nDPI modifies the ALPN string by:
1. Adding null terminators that truncate the last character
2. Converting semicolons to dashes, affecting multi-protocol ALPNs
This complete fix:
- Adds alpn_original_last field to store the true last character
- Captures the last character of the FIRST ALPN protocol only (before ;/,)
- Preserves the original character before nDPI's string modifications
Now correctly implements JA4 spec: first + last characters of first ALPN protocol
Examples:
- ALPN 'h2;http/1.1' -> 'h2' (not 'h.' or 'h1')
- ALPN 'http/1.1' -> 'h1' (not 'ht' or 'h.')
Fixes: #2914
* Fix JA4 SNI detection to properly handle missing SNI extensions
Previously, nDPI incorrectly set JA4 SNI flag to 'd' (domain present) for
flows without any SNI extension. This was because the logic only checked
for NDPI_NUMERIC_IP_HOST risk (set when SNI contains IP) but didn't
distinguish between missing SNI and domain SNI.
Now properly detects:
- No SNI extension → 'i' flag
- SNI with IP address → 'i' flag
- SNI with domain → 'd' flag
This matches the JA4 specification.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Removing JA3C is an big task. Let's start with a simple change having an
huge impact on unit tests: remove printing of JA3C information from
ndpiReader.
This way, when we will delete the actual code, the unit tests diffs
should be a lot simpler to look at.
Note that the information if the client/server cipher is weak or
obsolete is still available via flow risk
See: #2551
|
| |
|
|
| |
Show JA4C and JA3S information (instead of JA3C and JA3S)
See #2551 for context
|
| | |
|
| |
|
| |
In the same flow, we can have multiple multimedia types
|
| |
|
|
| |
port that was supposed to be used as default
|
| |
|
|
| |
Let's see if we are able to tell audio from video calls only looking at
RTP Payload Type field...
|
| | |
|
|
|
Allow nDPI to process the entire flows and not only the first N packets.
Usefull when the application is interested in some metadata spanning the
entire life of the session.
As initial step, only STUN flows can be put in monitoring.
See `doc/monitoring.md` for further details.
This feature is disabled by default.
Close #2583
|