| Commit message (Collapse) | Author | Age |
... | |
| |
|
|
|
| |
Credits to @LTxAlves
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Some old libpcap versions don't handle pcap files with capture length
bigger than 262144 bytes
```
ERROR: could not open pcap file: invalid interface capture length 524288, bigger than maximum of 262144
```
|
|
|
| |
Close #2738
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Close #2524
|
| |
|
|
|
|
|
| |
Try to populate the FPC-DNS cache using directly the info from the current
packet, and not from the metadata saved in `struct ndpi_flow_struct`. This
will be important when adding monitoring support
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
We already set the same flow risk for invalid request messages
|
| |
|
|
|
| |
Set the classification in only one place in the code.
|
| |
|
|
|
|
| |
If we have a (potential) valid sub-classification, we shoudn't check for
DGA, even if the subclassification itself is disabled!
|
|
|
|
| |
Prelimary change to start supporting multiple DNS transactions on the
same flow
|
| |
|
|
|
|
|
| |
We can't write to `flow->protos.dns` until we are sure it is a valid DNS
flow
|
| |
|
| |
|
|
|
|
| |
Updated (C)
|
| |
|
| |
|
|
|
|
|
| |
(#2709)
See: c669bb314
|
|
|
| |
Fix confidence value for same TCP flows
|
|
|
| |
Extend file configuration for just subclassification.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some scenarios, you might not be interested in flow metadata or
flow-risks at all, but you might want only flow (sub-)classification.
Examples: you only want to forward the traffic according to the
classification or you are only interested in some protocol statistics.
Create a new configuration file (for `ndpiReader`, but you can trivially
adapt it for the library itself) allowing exactly that. You can use it
via: `ndpiReader --conf=example/only_classification.conf ...`
Note that this way, the nDPI overhead is lower because it might need
less packets per flow:
* TLS: nDPI processes only the CH (in most cases) and not also the SH
and certificates
* DNS: only the request is processed (instead of both request and
response)
We might extend the same "shortcut-logic" (stop processing the flow
immediately when there is a final sub-classification) for others
protocols.
Add the configuration options to enable/disable the extraction of some
TLS metadata.
|
|
|
| |
Allow optimal FPC even if DNS subclassification is disabled
|
| |
|
| |
|
|
|
|
|
|
| |
* Rename `NDPI_PROTOCOL_SKYPE_TEAMS_CALL` ->
`NDPI_PROTOCOL_MSTEAMS_CALL`
* Rename ip list from "Skype/Teams" to "Teams"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mis-mapping to s3 (#2684)
* JA4: Fix SSL 2 version constant to 0x0002
SSL 2 uses a version field of 0x0002, not 0x0200. This is confirmed not
only in the original Netscape spec [1] and RFC draft of the time [2],
but also in major implementations such as OpenSSL [3] and Wireshark [4].
An earlier version of the JA4 spec [5] also mistakenly used 0x0200 for
SSL 2 and 0x0100 for SSL 1. This was fixed in [6] in August 2024.
[1] https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02.html
[2] https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00
[3] https://github.com/openssl/openssl/blob/OpenSSL_0_9_6m/ssl/ssl2.h#L66-L71
[4] https://github.com/wireshark/wireshark/blob/release-4.4/epan/dissectors/packet-tls-utils.h#L266-L277
[5] https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md#tls-and-dtls-version
[6] FoxIO-LLC/ja4#150
* JA4: Remove fictional (and mis-mapped to "s3") SSL 1
SSL 1 was never actually deployed, the design was iterated upon to
become SSL 2 before it was released by Netscape [1] [2] [3] [4]. I
don't think it's public knowledge what the version field for SSL 1 would
have looked like, or if it even was two bytes large or at the same
offset on the wire; given that SSL 2 used 0x0002 it seems more likely to
have been 0x0001 than 0x0100.
Version field 0x0100, that is currently misattributed to SSL 1, was used
by an early pre-RFC4347 implementation of DTLS in OpenSSL before 0.9.8f
[5], when OpenSSL switched to the version field specified by RFC4347.
This use of 0x0100 is also reflected in Wireshark's TLS dissector [4]
(`DTLSV1DOT0_OPENSSL_VERSION`).
For these reasons, it seems to make sense to remove the fictional SSL 1
code entirely.
This also removes an issue where the resulting JA4 string would be "s3"
instead of the intended "s1".
An earlier version of the JA4 spec [6] also mistakenly used 0x0200 for
SSL 2 and 0x0100 for SSL 1. This was fixed in [7] in August 2024.
[1] https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02.html
[2] https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00
[3] https://github.com/openssl/openssl/blob/OpenSSL_0_9_6m/ssl/ssl2.h#L66-L71
[4] https://github.com/wireshark/wireshark/blob/release-4.4/epan/dissectors/packet-tls-utils.h#L266-L277
[5] https://github.com/openssl/openssl/compare/OpenSSL_0_9_8e...OpenSSL_0_9_8f
[6] https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md#tls-and-dtls-version
[7] FoxIO-LLC/ja4#150
* Fix tests where old DTLS (0x0100) was mis-identified as SSL 3.0
These two tests contain DTLS flows using a version field of 0x0100 as
used by OpenSSL pre 0.9.8f, before OpenSSL switched to the standardised
version code points for its DTLS implementation. The correct JA4
mapping is "d00", not "ds3".
|
| |
|
|
|
| |
Enabled via `--dump-fpc-stats` option
|
| |
|