The basic idea is to have the following logic:
* pattern "DOMAIN" matches the domain itself (i.e exact match) *and* any
subdomains (i.e. "ANYTHING.DOMAIN")
* pattern "DOMAIN." matches *also* any strings for which is a prefix
[please, note that this kind of match is handy but it is quite
dangerous...]
* pattern "-DOMAIN" matches *also* any strings for which is a postfix
Examples:
* pattern "wikipedia.it":
* "wikipiedia.it" -> OK
* "foo.wikipedia.it -> OK
* "foowikipedia.it -> NO MATCH
* "wikipedia.it.com -> NO MATCH
* pattern "wikipedia.":
* "wikipedia.it" -> OK
* "foo.wikipedia.it -> OK
* "foowikipedia.it -> NO MATCH
* "wikipedia.it.com -> OK
* pattern "-wikipedia.it":
* "wikipedia.it" -> NO MATCH
* "foo.wikipedia.it -> NO MATCH
* "0001-wikipedia.it -> OK
* "foo.0001-wikipedia.it -> OK
Bottom line:
* exact match
* prefix with "." (always, implicit)
* prefix with "-" (only if esplicitly set)
* postfix with "." (only if esplicitly set)
That means that the patterns cannot start with '.' anymore.
Close#2330
Follow up of 31c706c3db and
75485e177c.
Allow fast classification by ip, but give time to other dissectors to
kick in (for example, the TLS code for the Telegram Web flows).
Even if we don't classify it anymore at the very first packet (i.e. SYN)
we fully classify Telegram traffic at the first packet with payload, as
*any* other protocol.
This way, we always have the proper category, the proper confidence
for the UDP flows and we don't overwrite previous classifications (TLS
or ICMP)
Remove old and stale identification logic for TCP flows
Skype has been using standard protocols (STUN/ICE or TLS) for a long,
long time, now. Long gone are the days of Skype as a distribuited
protocol.
See: #2166
* Add detection of Gaijin Entertainment games
* Short NDPI_PROTOCOL_GAIJINENTERTAINMENT to NDPI_PROTOCOL_GAIJIN
* Add default UDP port for Gaijin Entertainment games
* Remove NDPI_PROTOCOL_CROSSOUT protocol id
QUIC decryption fails when the Client Hello is split into multiple UDP
packets and these packets have different Destination Connection IDs
(because the server told the client to switch to a different CID; see
RFC 9000 7.2)
```
The Destination Connection ID field from the first Initial packet sent by
a client is used to determine packet protection keys for Initial packets.
[..]
Upon first receiving an Initial or Retry packet from the server, the
client uses the Source Connection ID supplied by the server as the
Destination Connection ID for subsequent packets
```
From a logical point of view, the ciphers used for decryption should be
initialized only once, with the first Initial pkt sent by the client and
kept for later usage with the following packets (if any).
However it seems that we can safely initialize them at each packet, if
we keep using the DCID of the **first** packet sent by the client.
Keep initializing the ciphers at each packet greatly simplifie this patch.
This issue has been undetected for so long because:
* in the vast majority of the cases we only decrypt one packet per flow;
* the available traces with the Client Hello split into multiple packets
(i.e. cases where we need to decrypt at least two packets per flow) were
created in a simple test environment to simulate Post-Quantum handshake,
and in that scenario the client sent all the packets (with the same
DCID) before any reply from the server.
However, in the last months all major browsers started supporting PQ
key, so it is now common to have split CH in real traffic.
Please note that in the attached example, the CH is split into 2
(in-order) fragments (in different UDP packets) and the second one in
turn is divided into 9 (out-of-order) CRYPTO frames; the reassembler
code works out-of-the-box even in this (new) scenario.
* Fix detection of new Cassandra versions
* Add Cassandra Internode Communication protocol support
* Add default port for Cassandra Internode Communication protocol
Having smaller traces help fuzzing: we want the fuzzers to mutate
"interesting" packets analyzed by nDPI, i.e. the first packets of each
flows.
Try hard to keep the same classification and extraction capabilities
We already have a generic (and up to date) logic to handle ip addresses:
remove that stale list.
Teamviewer uses TCP and UDP, both; we can't access `flow->l4.udp`.
According to a comment, we set the flow risk
`NDPI_DESKTOP_OR_FILE_SHARING_SESSION` only for the UDP flows.
* Add WebDAV detection support
* Add pcap example
* Update test results
* Remove redundant checks
* Add WebDAV related HTTP methods to fuzz/dictionary.dict
* Add note about WebDAV
It is quite simple (and not so efficient) but it should fix all the
false positives reported in #2216. Add support for Ethereum mining.
Merge all the mining traces.
Remove duplicated function.
Close#2216
