On Apr 9, 2024, at 6:02 PM, David Cunningham via sr-users <sr-users(a)lists.kamailio.org> wrote:  Hello, We're using kamailio, with rtpengine for RTP encryption/decryption. It works fine but I would like to understand the integration better. How does rtpengine get the TLS certificates, and what crypto library does it use (openssl?). Thank you in advance, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

On 09/04/2024 17.40, David Cunningham via sr-users wrote: SRTP itself doesn't use any certificates, and is not TLS. The underlying cipher (AES) is provided by OpenSSL, while the SRTP implementation itself is its own. TLS and certificates are relevant when it comes to the key exchange. With SDES, keys are exchanged in-line and nothing else is needed. The other option is DTLS: Here a self-signed certificate is used (generated at startup), and keys are exchanged using the DTLS implementation provided by OpenSSL. The certificate's fingerprint is exchanged in-line and that's how the peer's certificate is verified. After the key exchange completes, the SRTP keys are extracted from the handshake, DTLS is done, and the rest is just regular SRTP. Cheers __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

sr-users(a)lists.kamailio.org> wrote: the rtpengine_manage() lines have "SDES-off", so presumably then we are using DTLS? Exactly so. My response was more presumptuous than Richard's, because SDES has fallen out of fashion. Exchanging keys directly in the SDP body is rather suboptimal from a security standpoint, even if the signalling is encrypted, but it's certainly simpler. I suppose that makes DTLS "more secure", but in every other sense, I'm not sure DTLS is "better". W3C WebRTC standards mandate DTLS-SRTP, as far as I know, so I suppose it's more fit for that purpose. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

On 09/04/2024 23.14, Alex Balashov via sr-users wrote: Exchanging keys directly in the SDP body is rather suboptimal from a security standpoint, even if the signalling is encrypted, but it's certainly simpler. I suppose that makes DTLS "more secure", but in every other sense, I'm not sure DTLS is "better". W3C WebRTC standards mandate DTLS-SRTP, as far as I know, so I suppose it's more fit for that purpose. To add to that, one benefit DTLS has over SDES is that key exchange can happen as soon as media can flow, which theoretically can be immediately after the initial offer (invite), especially if ICE is also in use, as is the case with WebRTC. Whereas with SDES, since key exchange happens in-line with the signalling, key exchange can only be completed once an answer to the initial offer has been received. Which means that at least in theory DTLS is faster to establish media than SDES is. (Caveat: Not all DTLS clients actually allow this.) As for security: The most commonly used SRTP key types that can be exchanged are the same between SDES and DTLS, so in this aspect neither is more secure than the other. As for key exchange itself, DTLS is more sophisticated as it uses a peer-to-peer (with rtpengine being one of the peers in your case) public-key exchange to set up SRTP, whereas SDES relies on the signalling transport to be encrypted, which almost certainly isn't the case peer-to-peer (i.e. any involved signalling gateway or proxy can inspect or possibly modify the keys). In theory DTLS also allows extra trust to be established via verification of the DTLS certificates, but in practice this isn't usually done as the certificates are often self-signed. Cheers __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

On 10/04/2024 17.46, David Cunningham wrote: DTLS is entirely provided by OpenSSL, except for the raw network I/O. Once the DTLS handshake completes, the SRTP keys are extracted out of OpenSSL. The cipher implementation (AES) as well as the digest implementation (SHA-1) are provided by OpenSSL. For AEAD-GCM, the entire encryption, decryption, and authentication process is handled by OpenSSL. For the other cipher suites (AES-CM, AES-F8), OpenSSL is used to create the block key via AES, and then rtpengine has its own implementation of the counter-mode cipher to apply the AES key to the SRTP payload. This is because SRTP uses a peculiar version of AES-CM that OpenSSL doesn't directly support. (This really isn't much more than XOR'ing the AES key onto the SRTP payload and so isn't really doing much cryptography.) For SRTP in the kernel module, it's more or less exactly the same, except that the kernel's crypto API is used instead of OpenSSL. (DTLS is done in userspace only.) Cheers