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,
Hello,
The encryption mechanism is called DTLS-SRTP, and you might think of it best as just TLS over UDP. The certificate is dynamically generated by RTPEngine. It is somewhat simpler than what you might think of as full-blown TLS. The APIs used for this are indeed OpenSSL.
— Sent from mobile, apologies for brevity and errors.
On Apr 9, 2024, at 6:02 PM, David Cunningham via sr-users sr-users@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@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:
How does rtpengine get the TLS certificates, and what crypto library does it use (openssl?).
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
Hi Richard and Alex,
Thank you very much for the information. In our Kamailio configuration the rtpengine_manage() lines have "SDES-off", so presumably then we are using DTLS?
Are either SDES or DTLS considered more secure or "better" in any way?
On Wed, 10 Apr 2024 at 10:32, Richard Fuchs via sr-users < sr-users@lists.kamailio.org> wrote:
On 09/04/2024 17.40, David Cunningham via sr-users wrote:
How does rtpengine get the TLS certificates, and what crypto library does it use (openssl?).
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@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 Apr 9, 2024, at 7:25 PM, David Cunningham via sr-users sr-users@lists.kamailio.org wrote:
Thank you very much for the information. In our Kamailio configuration 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.
Are either SDES or DTLS considered more secure or "better" in any way?
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
Thank you Alex!
On Wed, 10 Apr 2024 at 15:26, Alex Balashov via sr-users < sr-users@lists.kamailio.org> wrote:
On Apr 9, 2024, at 7:25 PM, David Cunningham via sr-users <
sr-users@lists.kamailio.org> wrote:
Thank you very much for the information. In our Kamailio configuration
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.
Are either SDES or DTLS considered more secure or "better" in any way?
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@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
Thank you Richard, it does sound like DTLS is an improvement then.
I was asking whether OpenSSL was used because of a question we had about FIPS validation. FIPS requires that all cryptography components go through a validation process, which some versions of OpenSSL (but not all) have done.
My understanding is that RTPengine uses OpenSSL for the AES, but not for all of the key functions. Is that right? If so then even if we're using a FIPS validated version of OpenSSL, not all of the cryptography components of RTPengine would be using it, so we wouldn't be fully FIPS validated.
On Wed, 10 Apr 2024 at 22:50, Richard Fuchs via sr-users < sr-users@lists.kamailio.org> wrote:
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@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:
I was asking whether OpenSSL was used because of a question we had about FIPS validation. FIPS requires that all cryptography components go through a validation process, which some versions of OpenSSL (but not all) have done.
My understanding is that RTPengine uses OpenSSL for the AES, but not for all of the key functions. Is that right? If so then even if we're using a FIPS validated version of OpenSSL, not all of the cryptography components of RTPengine would be using it, so we wouldn't be fully FIPS validated.
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
Thanks Richard. It was "SRTP uses something that OpenSSL doesn't directly support" that our FIPS expert told us, which led us down this line of enquiry. I didn't understand exactly what the something was, but your explanation makes sense.
On Thu, 11 Apr 2024 at 10:41, Richard Fuchs rfuchs@sipwise.com wrote:
On 10/04/2024 17.46, David Cunningham wrote:
I was asking whether OpenSSL was used because of a question we had about FIPS validation. FIPS requires that all cryptography components go through a validation process, which some versions of OpenSSL (but not all) have done.
My understanding is that RTPengine uses OpenSSL for the AES, but not for all of the key functions. Is that right? If so then even if we're using a FIPS validated version of OpenSSL, not all of the cryptography components of RTPengine would be using it, so we wouldn't be fully FIPS validated.
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
-
Alex Balashov -
David Cunningham -
Richard Fuchs