RTP: treat it as an encrypted protocol.

[IvanNardi]

The goal is to have "RTP.ZOOM" flows classified as "Encrypted" and not as "Cleartext".

To be fair, RTP might be in cleartext (meaning: you can play the media stream without any other info than the flow itself) but nowadays RTP is almost always encrypted (i.e SRTP), especially on the public internet.

The other solution would be to add a special case for RTP in ndpi_is_encrypted_proto() (plain RTP -> cleartext, RTP as master -> encrypted, or depending on the app), but it seemed overwhelming.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[lucaderi]

The idea is not bad per-se, just wondering if it add another problem for non-encrypted RTP. To make things clear IMHO we should check inside RTP the media type and if it's proprietary as in Zoom and Teams, mark it as encrypted. What do you think?

[IvanNardi]

Something like that?

u_int8_t ndpi_is_encrypted_proto(struct ndpi_detection_module_struct *ndpi_str,
				                             ndpi_protocol proto) {
[...]
  if(ndpi_is_valid_protoId(proto.master_protocol) && ndpi_is_valid_protoId(proto.app_protocol)) {
    /* RTP itself might be in cleartext, but if it is a master protocol, the flow is usually encrypted (examples: RTP.Zoom or RTP.Teams */
    if(proto.master_protocol == NDPI_PROTOL_RTP) {
      return !ndpi_str->proto_defaults[proto.app_protocol].isClearTextProto;
    }
  }
[...]
}

[We can't tell if RTP is encrypted or not only looking at the RTP Payload Type field]

Another possibility: introduce NDPI_PROTOCOL_SRTP (encrypted, obviously) and classify those Zoom flows as SRTP.Zoom

[IvanNardi]

Thinking a lit bit more, the SRTP solution seems the cleaner one: RTP -> cleartext; SRTP -> encrypted

[IvanNardi]

Superseded by #1977