| 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));
```
|
| | |
|
| |
|
|
| |
Use the same breed value for both standard and content-matching
classification
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| | |
|
| | |
|
| |
|