ProtonVPN script have been not working in the last week.
```
Error "Invalid access token"
```
ProtonVPN is doing a major upgrade in its infrastructure:
```
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Apr 09, 2025 - 11:30 CEST
Scheduled - In the following period from the 9th of April up to the 30th of April, various Proton VPN dedicated servers will be in temporary maintenance mode, for a short duration period, in order to allow us to perform a major infrastructure upgrade, paving the way for overall increased performance and efficiency of our Proton VPN infrastructure.
We apologize for the occasional inconvenience.
Apr 9, 2025 11:30 - Apr 30, 2025 23:30 CEST
```
Let's wait if it works again in the future...
Use `NDPI_OBFUSCATED_TRAFFIC` instead; this way, all the obfuscated
traffic is identified via `NDPI_OBFUSCATED_TRAFFIC` flow risk.
Disable fully-encryption detection by default, like all the obfuscation
heuristics.
That flow risk was introduced in 79b89d2866
but we can now use the generic `NDPI_TLS_SUSPICIOUS_EXTENSION` instead:
ESNI is quite suspicious nowadays in itself (i.e. even without SNI).
Note that ESNI support has been removed in cae9fb9989
These flows are already classified as TLS.RDP.
This change also fix a memory leak
```
Direct leak of 62 byte(s) in 1 object(s) allocated from:
#0 0x5883d762429f in __interceptor_malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:68:3
#1 0x5883d76fe46a in ndpi_malloc ndpi/src/lib/ndpi_memory.c:57:46
#2 0x5883d76fe46a in ndpi_strdup ndpi/src/lib/ndpi_memory.c:110:13
#3 0x5883d77adcd6 in ndpi_compute_ja4 ndpi/src/lib/protocols/tls.c:2298:46
#4 0x5883d77ab2ec in processClientServerHello ndpi/src/lib/protocols/tls.c:3314:10
#5 0x5883d77a4c51 in processTLSBlock ndpi/src/lib/protocols/tls.c:1319:5
```
Found by oss-fuzz.
See: https://oss-fuzz.com/testcase-detail/5244512192757760
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)
Custom rules with *new* protocols are checked "first": if there is a
match, the first packet of the flow provides a complete and final
classification.
The same logic should apply to custom rules with "existing" protocols:
if there is match, nDPI shouldn't do anything else.
Remove the `tcp:3000@ntop` custom rule.
Fix the default port for ElasticSearch (in the protocol file)
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.
There are no reasons to keep entropy calculation and sanity checks code
on the "guessing" algorithm.
BTW, this change also fix the entropy calculation for non TCP/UDP/ICMP
flows
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
```
