Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

@utoni, could you give me some time before merging that, please?

Naturalmente.

@utoni , thanks for your patience.

I see the goal here: restore CiscoVPN classification for the flow 10.0.0.227:56320 <-> 10.0.0.149:8009 of tests/pcap/anyconnect-vpn.pcap after 1016144 (note that this flow is a mid-flow: we don't have the initial handshake)

I agree with that goal. However, what I don't really like is adding a (small) overhead to all the TLS flows, always looking for a CiscoVPN matching: it seems overkilling. This is my concern about that patch.

Some thoughts about Anyconnect.

First thing first: AFAIU, to use anyconnect you need a Cisco licence and I didn't find a lot of documentation, nor some other traces: therefore, I am not able to thoroughly test it.

Looking at the code, this protocol is recognized via some patterns (and some ports):

• the first pattern "0x17 0x01 0x00 0x00" matches every DTLS 1.0 Application Data packet with Epoch < 256 (i.e. pretty much all of them)
• the second pattern "0x17 0x03 0x03 0x00 0x69" matches every TLS 1.3 Application Data packet with length 105 (!?)
• the third pattern is "0xFE 0x57 0x7E 0x2B" (only on port 10000): no idea about this one, it is not triggered by the internal tests and it came directly from OpenDPI code
• the fourth pattern "0x17 0x01 0x00 0x00 0x01" matches every DTLS 1.0 Application Data packet with Epoch == 1 (i.e. pretty much all of them)

Some words about the ports. No idea where 8008/8009 come from; the only official reference I found about 10000 is years old (https://community.cisco.com/t5/vpn/what-are-the-ports-used-by-cisco-vpn-client/td-p/260713) and it is about IPSEC over UDP (in that case the first bytes of the packets are always the SPI, i.e. some random number).
Newest info are only about 443 on standard TLS/DTLS sessions (https://community.cisco.com/t5/vpn/ssl-vpn-udp-or-tcp/td-p/3830338)

The only reason nDPI seems to match some CiscoVPN flows is because (D)TLS dissector doesn't handle DTLS 1.0 (but only newer versions); If I add support for it, all these flows are classified as DTLS.

Bottom line: CiscoVPN dissector is extremely weak in the first place and it seems to search only for mid-flows which are virtually identical to standard TLS/DTLS traffic. Maybe we are able to detect CiscoVPN if we have the initial TLS/DTLS handshakes but all bets seem off for mid-flows.

After that rant (sorry!), I am not opposing this patch anyway: feel free to merge it, if you think it might be useful!

@utoni , thanks for your patience.

I see the goal here: restore CiscoVPN classification for the flow 10.0.0.227:56320 <-> 10.0.0.149:8009 of tests/pcap/anyconnect-vpn.pcap after 1016144 (note that this flow is a mid-flow: we don't have the initial handshake)

So we need to find/create a decent pcap first to verify the dissector results.

I agree with that goal. However, what I don't really like is adding a (small) overhead to all the TLS flows, always looking for a CiscoVPN matching: it seems overkilling. This is my concern about that patch.

Do you think that this small overhead may have measurable performance impacts?

First thing first: AFAIU, to use anyconnect you need a Cisco licence and I didn't find a lot of documentation, nor some other traces: therefore, I am not able to thoroughly test it.

So we will need help from someone who uses Cicsco and nDPI. Maybe someone from the community can help us here.

Looking at the code, this protocol is recognized via some patterns (and some ports):

• the first pattern "0x17 0x01 0x00 0x00" matches every DTLS 1.0 Application Data packet with Epoch < 256 (i.e. pretty much all of them)
• the second pattern "0x17 0x03 0x03 0x00 0x69" matches every TLS 1.3 Application Data packet with length 105 (!?)
• the third pattern is "0xFE 0x57 0x7E 0x2B" (only on port 10000): no idea about this one, it is not triggered by the internal tests and it came directly from OpenDPI code
• the fourth pattern "0x17 0x01 0x00 0x00 0x01" matches every DTLS 1.0 Application Data packet with Epoch == 1 (i.e. pretty much all of them)

Some words about the ports. No idea where 8008/8009 come from; the only official reference I found about 10000 is years old (https://community.cisco.com/t5/vpn/what-are-the-ports-used-by-cisco-vpn-client/td-p/260713) and it is about IPSEC over UDP (in that case the first bytes of the packets are always the SPI, i.e. some random number).

Agreed. I am in general not a friend of port based DPI. But I guess for proprietary applications it may work. Nevertheless, we need to get our hands on some real traffic, not that midstream nonsense.

Newest info are only about 443 on standard TLS/DTLS sessions (https://community.cisco.com/t5/vpn/ssl-vpn-udp-or-tcp/td-p/3830338)

The only reason nDPI seems to match some CiscoVPN flows is because (D)TLS dissector doesn't handle DTLS 1.0 (but only newer versions); If I add support for it, all these flows are classified as DTLS.

Bottom line: CiscoVPN dissector is extremely weak in the first place and it seems to search only for mid-flows which are virtually identical to standard TLS/DTLS traffic. Maybe we are able to detect CiscoVPN if we have the initial TLS/DTLS handshakes but all bets seem off for mid-flows.

After that rant (sorry!), I am not opposing this patch anyway: feel free to merge it, if you think it might be useful!

In that case I would support the removal of that sus cisco dissector until we have some usable pcaps.

Will close this PR and try something else.