* 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)
This way, the `ndpiReader` output doesn't change if we change the
internal logic about the order we set/check the various flow risks.
Note that the flow risk *list* is already printed by `ndpiReader`
in order.
It might be usefull to be able to match traffic against a list of
suspicious JA4C fingerprints
Use the same code/logic/infrastructure used for JA3C (note that we are
going to remove JA3C...)
See: #2551
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
* Revert "Added fix for handling Server Hello before CLient Hello"
This reverts commit eb15b22e77.
* TLS: add some tests with unidirectional traffic
* TLS: another attempt to process CH received after the SH
Obviously, we will process unidirectional traffic longer, because we are
now waiting for messages in both directions
The Train Real Time Data Protocol (TRDP) is a UDP/TCP-based communication protocol designed for IP networks in trains, enabling data exchange between devices such as door controls and air conditioning systems. It is standardized by the IEC under IEC 61375-2-3 and is not related to the Remote Desktop Protocol (RDP).
ISO/IEC 14908-4 defines how to tunnel Control Network Protocol (CNP) over IP networks. It encapsulates protocols like EIA-709, EIA-600, and CNP, making it a versatile solution for building automation and control systems.
