[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
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 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 > > -- 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-le...@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] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@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] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
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-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > -- 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-le...@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] show final SIP INVITE before going out
hi,
i have kamailio with TLS
i dont have homer and voipmonitor with TLS decryption doesnt work
how can i check final SIP INVITE (after all rewrites/modifications)
before is send to the peer?
tried
onsend_route {
if ($rm == "INVITE") {
xlog("L_INFO", "Final SIP Message before
Sending: $mbu\n");
}
}
but record-route/via are different than reality (checked with sngrep
with TLS disabled)
kamailio log
Record-Route: Via: SIP/2.0/UDP
9.9.9.9;branch=z9hG4bKsr-2y7Ud3XCMD4N6Vi8M-iCM-XGdWSBMDGzuhJZu-iGMh9ztEu7q.
10.10.10.10 - private kamailio ip (fictional)
30.30.30.30 - ip of SIP PBX (caller)
9.9.9.9 - public kamailio ip
Marek
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@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] Re: Solution found: Race condition in dialog on 422 reply deletes variables.
Hello Benoit, yes, there have been multiple reports of setflag together with dialog does not working correctly over the years, and dlg_manage needs to be used. We probably should remove the setflag for dialog to prevent confusion. Cheers, Henning > -Original Message- > From: Benoit Panizzon via sr-users > Sent: Montag, 8. April 2024 16:17 > To: Benoît Panizzon via sr-users > Cc: Benoit Panizzon > Subject: [SR-Users] Solution found: Race condition in dialog on 422 reply > deletes variables. > > Hi all > > I have found another solution: > > Don't use: setflag(FLT_DLG); > > call dlg_manage() on every message entering request_route before trying to > set dlg_vars. > > On a 422 reply I now get two CDR, but that is OK as long as I have correct > dlg_vars on the second almost identical call (endpoint immediately re-sending > the invite with smaller session timer) which is then connected and which I > need for billing. > > Mit freundlichen Grüssen > > -Benoît Panizzon- > -- > I m p r o W a r e A G-Leiter Commerce Kunden > __ > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > CH-4133 PrattelnFax +41 61 826 93 01 > Schweiz Web http://www.imp.ch > __ > __ > Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe > send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@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] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
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-le...@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] Re: Urgent: High CPU Load and MySQL Connection Issue on Kamailio Proxy Server
Try to check MySQL logs *Antony* satski...@gmail.com +380669197533 +48727830247 On Wed, 10 Apr 2024 at 09:12, satyaprakash ch via sr-users < sr-users@lists.kamailio.org> wrote: > Hi, > > We're encountering a CPU load of approximately 90% on the Kamailio proxy > server. Additionally, there's an error logged indicating a lost connection > to MySQL. Could this indicate a problem with the configuration file or is > it related to MySQL itself? Your guidance would be appreciated. > > MySQL version: Ver 14.14 Distrib 5.5.47 > Kamailio version: 5.5.5 > > Error in logs: > /usr/local/sbin/kamailio[24933]: ERROR: db_mysql [km_dbase.c:122]: > db_mysql_submit_query(): driver error on query: Lost connection to MySQL > server during query (2013) > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
