Add Shellfire VPN support

[0xA50C1A1]

Please sign (check) the below before submitting the Pull Request:

• I have signed the ntop Contributor License Agreement at https://github.com/ntop/legal/blob/main/individual-contributor-licence-agreement.md
• I have read the contributing guide lines at https://github.com/ntop/nDPI/blob/dev/CONTRIBUTING.md
• I have updated the documentation (in doc/) to reflect the changes made (if applicable)

Describe changes:

Yet another VPN service out of the thousands. This one is operated by the German company Shellfire GmbH.

[sonarcloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

2 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[IvanNardi]

@0xA50C1A1, Just out of curiosity: are you going to push other similar VPN stuff?

[0xA50C1A1]

@0xA50C1A1, Just out of curiosity: are you going to push other similar VPN stuff?

Yea, I was thinking of adding some more VPN stuff that I sometimes use.

[0xA50C1A1]

@IvanNardi Btw, what do you think, how hard is to implement cert extraction for OpenVPN with TLS auth in nDPI? That would be a really useful feature.

[IvanNardi]

@0xA50C1A1, Just out of curiosity: are you going to push other similar VPN stuff?

Yea, I was thinking of adding some more VPN stuff that I sometimes use.

I am going to accept this PR anyway
But I have some doubts about how useful is to have lots of ID for different VPNs which simply use a plain and un-distinguishable version of OpenVPN /Wireguard/IPsec for the "real" data flows. I mean, these TLS/DNS domains only indicates that you visited the site or you opened the app, not that you are really using the VPN...
Maybe classify these domains as simple TLS traffic with VPN category (like gambling) or with a generic id like PROTOCOL_GENERIC_VPN?

Just some thoughts... @0xA50C1A1, @lucaderi , @utoni

[0xA50C1A1]

But I have some doubts about how useful is to have lots of ID for different VPNs which simply use a plain and un-distinguishable version of OpenVPN /Wireguard/IPsec for the "real" data flows.

Well, in case of OpenVPN with TLS auth it's possible to extract some information from the cert.

Maybe classify these domains as simple TLS traffic with VPN category (like gambling) or with a generic id like PROTOCOL_GENERIC_VPN?

I agree. Nowadays there are more VPN services than a dog got fleas, so it would be wasteful to create a new id for each one.

[IvanNardi]

Well, in case of OpenVPN with TLS auth it's possible to extract some information from the cert.

Yes. I was only talking about VPN where we can't extract any other information than plain OpenVPN/Wireguard/... if we are able to tell one specific VPN from another (for the "real" traffic), it makes sense to have a dedicated ID

[IvanNardi]

@IvanNardi Btw, what do you think, how hard is to implement cert extraction for OpenVPN with TLS auth in nDPI? That would be a really useful feature.

See #2254

[utoni]

IMHO the SNIs a pretty generic. So by just visiting the websites, nDPI will classify that https traffic as VPN, which is kind of a false-positive. Is it possible to use the client or server hello to see if it is a Webbrowser or VPN Client that wants to communicate?

[IvanNardi]

Is it possible to use the client or server hello to see if it is a Webbrowser or VPN Client that wants to communicate?
AFAIK, no, it is not.

Are you saying that we should use NDPI_PROTOCOL_CATEGORY_VPN only for the "real/encrypted" data and not for the generic traffic of the app or to the websites? It would makes sense: we should review the list in src/lib/ndpi_content_match.c.inc in that case...

[0xA50C1A1]

Ok, I'll change this PR to a draft for a while.