* 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
This cache was added in b6b4967aa, when there was no real Zoom support.
With 63f349319, a proper identification of multimedia stream has been
added, making this cache quite useless: any improvements on Zoom
classification should be properly done in Zoom dissector.
Tested for some months with a few 10Gbits links of residential traffic: the
cache pretty much never returned a valid hit.
Avoid code duplication between these two protocols.
We remove support for RTCP over TCP; it is quite rare to find this kind
of traffic and, more important, we have never had support for RTP
over TCP: we should try to add both detecion as follow-up.
Fix a message log in the LINE code
The new values has been checked against the ones reported by Wireshark.
Found while fixing a Use-of-uninitialized-value error reported by
oss-fuzz
```
==7582==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x5a6549abc368 in ndpi_compute_ja4 ndpi/src/lib/protocols/tls.c:1762:10
#1 0x5a6549ab88a0 in processClientServerHello ndpi/src/lib/protocols/tls.c:2863:10
#2 0x5a6549ac1452 in processTLSBlock ndpi/src/lib/protocols/tls.c:909:5
#3 0x5a6549abf588 in ndpi_search_tls_tcp ndpi/src/lib/protocols/tls.c:1098:2
#4 0x5a65499c53ec in check_ndpi_detection_func ndpi/src/lib/ndpi_main.c:7215:6
```
See: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68449&q=ndpi&can=1&sort=-id
eDonkey is definitely not as used as >10 years ago, but it seems it is
still active.
While having a basic TCP support seems easy, identification over UDP doesn't
work and it is hard to do it rightly (packets might be only 2 bytes long):
remove it.
Credits to V.G <v.gavrilov@securitycode.ru>
P2P video player PPStream was discontinued shortly after the purchase of PPS.tv by Baidu (iQIYI) on 2013 (see https://www.techinasia.com/report-baidu-acquires-video-rival-pps)
So we remove the old `NDPI_PROTOCOL_PPSTREAM` logic and add `NDPI_PROTOCOL_IQIYI` id to handle all the iQIYI traffic, which is basically video streaming traffic.
A video hosting service, called PPS.tv, is still offered by the same company: for the time being we classified both services with the same protocol id.
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
as explained here for bitcoin https://www.ntop.org/guides/nDPI/protocols.html#ndpi-protocol-bitcoin
the same is applicable for ethereum.
ethereum detection was removed from mining protocol and is now handled separately.
Signed-off-by: Mahmoud Maatuq <mahmoudmatook.mm@gmail.com>
Regardless of the name, the removed trace doesn't contain meaningful
Hangout traffic.
Remove last piece of sub-classifiction based only on ip addresses.
For a lot of protocols, reduce the number of packets after which the
protocols dissector gives up.
The values are quite arbitary, tring to not impact on classification
Extend internal unit tests to handle multiple configurations.
As some examples, add tests about:
* disabling some protocols
* disabling Ookla aggressiveness
Every configurations data is stored in a dedicated directory under
`tests\cfgs`
2023-04-06 11:30:36 +02:00
Renamed from tests/result/line.pcap.out (Browse further)
