DTLS

DTLS (Datagram Transport Layer Security) is a protocol used for securing the RTP voice or video streams. Voipmonitor uses the key received from the keylogger and from DTLS packets to make decryption possible

DTLS packets preceeding the RTP streams. Because the use of a keys from DTLS packets is possible after RTP packets arrives, and after keylogger packets arrives voipmonitor needs to store the DTLS packets aside from call struct - It is putting DTLS packets into a separate queue - until the assignation to a call/RTP stream/keylogger packet is possible.

Two ways on how to handle DTLS

Details

There are two methods by which VoIPmonitor can delay DTLS packets until the necessary packet from the keylogger and the first SRTP packets arrive for decryption.

1 DTLS processed with RTP

Parallel processing with RTP: If a DTLS packet is not assigned to any call, it goes into a queue. This queue is divided into streams based on IP/ports. If an encrypted RTP packet then arrives, it is checked whether there are DTLS packets in the queue. If so, they go into processing. Processing DTLS is thus part of RTP processing.

For this method, the existence of a DTLS queue is essential. Its behavior is determined by the following parameters:

ssl_dtls_queue = YES /no

Enables the queue; When no queue for the DTLS packets the dtls packet can miss the processing in case of a delay.

ssl_dtls_queue_expiration = default 10s

Defines expiration of DTLS packet in seconds. (After it expires, the DTLS packet gets removed from the queue)

ssl_dtls_queue_keep = yes / NO

This allows DTLS packets to remain in the queue even after their first successful use and to be discarded only upon their expiration; this is particularly useful if srtp_rtp_local_instances = yes is enabled (see below).

2 All DTLS packets go into a common processing

All DTLS packets go into a common processing. In this processing, DTLS packets are analyzed and the necessary information, such as client_random and server_random, is extracted. These data are sorted based on IP/ports. If an encrypted RTP packet arrives for RTP processing, it is checked whether the client_random and server_random data exist and whether the key has arrived from the keylogger. If so, the SRTP keys are calculated and decryption can proceed.

The interception of DTLS packets in this method is handled by a thread marked as ‘r’ in the log. It only passes RTP packets to further processing and is minimally loaded.

Method selection

Option ssl_dtls_handshake_safe allows You to choose which above method will be used:

NO (default) – 1)
yes – 1 & 2 (1 first)
ext – 1 & 2 (2 first)
only - 2

Special options

srtp_rtp_local_instances

New option srtp_rtp_local_instances (previously ssl_dtls_rtp_local) If this option is enabled, each RTP stream creates its own instance for decryption. Otherwise, the decryption instance is created jointly for SIP/SDP data based on the type of IP/port (in the sniffer for the index in the ip_port table).

ssl_sessionkey_keep

ssl_sessionkey_keep is not only related to DTLS. It ensures that the received keylogger key remains in processing until its expiration. Otherwise, it would be discarded after its first successful use. It is probably optimal for this option to be enabled by default.

ssl_dtls_boost

The sniffer has a pseudo-parameter ssl_dtls_boost. It is disabled by default. However, if enabled, it sets:

ssl_dtls_queue_expiration = 30
ssl_sessionkey_keep = yes
ssl_dtls_queue_keep = yes
ssl_dtls_handshake_safe = ext
ssl_dtls_rtp_local = yes