[SR-Users] Re: Setting $du to websocket-secure

Hi Daniel, Henning I tested the commit 60165196ad3144597c24eb9f7bb7fb0cd56f8c25 (which is the one after your fix https://github.com/kamailio/kamailio/commit/aa794581ecf105b5313d2f5b8bcfe51…). Although this gets my particular test INVITE working over TLS, it's not ideal because it can allow a WSS INVITE to be relayed over TCP and also allow a WS INVITE to be relayed over TLS (I'm not a C coder, but that's what I suspected when I read the commit, so I tested it). It seems as if the alias part ~5 or ~6 (for WS or WSS) is not fully respected. It's this scenario (the security problem of a TLS message being sent in the clear) for which PR 3810 (which Henning mentioned earlier) was made. That was important because an SBC might make multiple TCP/TLS connections on behalf of sub-customers and then a conflict can arise if/when a port get reused/shared. However, now I see these points. - This change affects only websocket, so doesn't completely undo the good of that PR. - A full/complete fix, I expect, might be much more complicated, because it would involve changing how $du works internally and involve nathelper as well as core. - Perhaps I'll deprecate the non-TLS websocket listener in my proxy server and then this won't matter any more. I expect that this will result in everything (Via transport parameter, Record-Route port, etc) working perfectly. Thanks for your quick fix on this. I think it's going to unblock a kamailio upgrade for me. James On Thu, 5 Sept 2024 at 08:59, James Browne &lt;james(a)frideo.com&gt; wrote: > Thanks, Henning. > Yes it looks like the same issue. > I see that Daniel pushed a commit an hour ago for this, so I'm going > to test it right now if I can and see what I can find. > > James > > On Thu, 5 Sept 2024 at 06:19, Henning Westerholt &lt;hw(a)gilawa.com&gt; wrote: >> Hello James, >> >> Thanks for sending the logs. I just briefly looked to the log files, at least the port 443 "wrong" scenario looks similar from the error message to the issue described here from somebody else: >> https://github.com/kamailio/kamailio/issues/3969 >> >> Cheers, >> >> Henning >> >>> -----Original Message----- >>> From: James Browne via sr-users &lt;sr-users(a)lists.kamailio.org&gt; >>> Sent: Mittwoch, 4. September 2024 12:23 >>> To: miconda(a)gmail.com >>> Cc: Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt;rg>; James >>> Browne &lt;james(a)frideo.com&gt; >>> Subject: [SR-Users] Re: Setting $du to websocket-secure >>> >>> Thanks, Daniel >>> Here are attached the logs with timestamps. I made two tests, involving >>> INVITEs that differed only in the Call-ID and CSeq. >>> In each case, the logs include the time of the websocket connection being >>> made. There was no other traffic on the server during the test. >>> >>> ############### >>> INVITE >>> sip:moon@bobbywomack.invalid;alias=11.15.32.1~33333~6;transport=ws >>> SIP/2.0 >>> Via: SIP/2.0/UDP 192.168.25.4:5060;rport;branch=z9hG4bK-d8754z- >>> cc2c63344f5218d >>> Route: <sip:10.25.17.11;lr;r2=on> >>> Route: <sip:198.18.55.66:443;transport=ws;lr;r2=on> >>> From: <sip:+353877900000@someclient>;tag=1a56f142c2ed4d2f >>> To: <sip:+35315220000@sip.frideo.eu> >>> ############### >>> >>> In log "port-80.txt", there was a websocket connection open to non-TLS port >>> 80, and the INVITE was relayed over it. >>> In log "port-443.txt", there was a websocket connection open to TLS port 443, >>> and the INVITE wasn't relayed. >>> >>> The kamailio.cfg was effectively this. >>> ############################################# >>> tcp_connection_match=1 >>> request_route { >>> route(INITIAL_INVITE_OUTGOING); >>> } >>> route[INITIAL_INVITE_OUTGOING] { >>> loose_route_preloaded(); >>> handle_ruri_alias(); >>> xlog("L_NOTICE", "[$ci] P1052 About to relay WS call to $dd:$dp from $fs >>> ($$du is $du)\n"); >>> if (!t_relay_to("0x02")) { >>> xlog("L_WARN", "[$ci] P1052 Failed relaying WS call to $dd:$dp\n"); >>> t_reply("503", "Relaying over WS to next hop failed"); >>> } >>> exit; >>> } >>> ############################################# >>> >>> James >>> >>> On Tue, 3 Sept 2024 at 15:53, Daniel-Constantin Mierla >>> &lt;miconda(a)gmail.com&gt; wrote: >>>> Hello, >>>> >>>> can you run with debug=3 in kamailio.cfg and attach all the debug >>>> messages printed by Kamailio in such case? It will help to figure out >>>> where it fails first to find properly the connection. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> On 03.09.24 15:24, James Browne wrote: >>>>> Thanks for your continued answers, Daniel. >>>>> >>>>> I have an edge proxy in front of the registrar. The edge proxy calls >>>>> add_contact_alias() whenever a REGISTER is received over websocket >>>>> (before relaying the REGISTER to the registrar). >>>>> >>>>> 2) Today I tested swapping the order of the loose_route() and >>>>> handle_ruri_alias() functions, but the result was the same. Always >>>>> if the RURI (after handle_ruri_alias() is called) has transport=ws >>>>> in it, then kamailio won't deliver it over a TLS websocket >>>>> connection (when tcp_connection_match is set). >>>>> >>>>> 1) So how can I set the $du to specify what websocket-over-tls >>>>> (rather than websocket-over-tcp-without tls) should be used? The >>>>> handle_ruri_alias() function does not achieve this when I test it. >>>>> Remember that "transport=ws" is used for both WS and WSS. >>>>> >>>>> James >>>>> >>>>> On Mon, 2 Sept 2024 at 16:00, Daniel-Constantin Mierla >>>>> &lt;miconda(a)gmail.com&gt; wrote: >>>>>> Hello, >>>>>> >>>>>> I didn't have the time to go in details over this discussion, but >>>>>> if I got it right quickly, then: >>>>>> >>>>>> 1) you can set $du to any SIP URI, where the transport parameter >>>>>> can be whatever you want >>>>>> >>>>>> 2) handle_ruri_alias() should be done after and loose-route processing. >>>>>> The Route headers are about intermediary hops, not the end points, >>>>>> and therefore they have to be consumed first. The ruri-alias should >>>>>> be about endpoint, so handling it has to be done by the last SIP >>>>>> proxy before the endpoint, where there is no other intermediary SIP hop >>> (proxy). >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> On 02.09.24 16:50, James Browne via sr-users wrote: >>>>>>> Thanks, Daniel >>>>>>> The problem is specifically about sending traffic to websocket >>>>>>> clients that have already established connections to my kamailio proxy. >>>>>>> >>>>>>> Thanks, Henning >>>>>>> You're right. That PR caused this problem, but it didn't really >>>>>>> _create_ a bug but highlighted one that was already there. >>>>>>> Before that PR, kamailio would relay traffic destined for a >>>>>>> websocket client via a WSS connection, but it was working only due >>>>>>> to two bugs that would cancel each other out. As far as I can >>>>>>> tell, this is how it worked. >>>>>>> - Kamailio would see the transport=ws and decide it would relay >>>>>>> the message over a TCP Websocket connection to the customer's TCP >>> port. >>>>>>> - Kamailio would see a TLS connection open using that >>>>>>> customer-side TCP port and relay what it was treating as a non-TLS >>>>>>> message through a TLS connection. >>>>>>> Of course, after that PR fixed the second bug, the first came to light. >>>>>>> >>>>>>> Anyway, is there a way to set the $du to a TLS-websocket URI? If >>>>>>> not, then this looks like a bug to me and I think I should log a >>>>>>> bug report. I've tested this thoroughly already and have a good >>>>>>> feel for it. >>>>>>> >>>>>>> (Full disclosure: I was involved with that PR 3810 that Henning >>>>>>> mentioned.) >>>>>>> >>>>>>> James >>>>>>> >>>>>>> On Fri, 30 Aug 2024 at 09:08, Henning Westerholt &lt;hw(a)gilawa.com&gt; >>> wrote: >>>>>>>> Hello James, >>>>>>>> >>>>>>>> It sounds a bit like a similar issue that was fixed some time ago >>>>>>>> for overlapping TCP and TLS sockets: >>>>>>>> https://github.com/kamailio/kamailio/pull/3810 >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Henning >>>>>>>> >>>>>>>> -- >>>>>>>> Henning Westerholt - https://skalatan.de/blog/ Kamailio services >>>>>>>> - https://gilawa.com >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: James Browne via sr-users &lt;sr-users(a)lists.kamailio.org&gt; >>>>>>>>> Sent: Donnerstag, 29. August 2024 13:35 >>>>>>>>> To: Kamailio (SER) - Users Mailing List >>>>>>>>> &lt;sr-users(a)lists.kamailio.org&gt; >>>>>>>>> Cc: James Browne &lt;james(a)frideo.com&gt; >>>>>>>>> Subject: [SR-Users] Setting $du to websocket-secure >>>>>>>>> >>>>>>>>> How can I set the destination URI for an INVITE to be a >>>>>>>>> websocket-secure destination? Is it possible? >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> I've a proxy with tcp_connection_match=1, but websocket URIs >>>>>>>>> always have transport=ws (never transport=wss) in them, so >>>>>>>>> relaying a call to a WSS connection always fails. >>>>>>>>> I tested running kamailio 6.0.0-dev2 compiled from a commit made >>> this week. >>>>>>>>> This proxy server uses nathelper rather than outbound module. >>>>>>>>> >>>>>>>>> Detail >>>>>>>>> We know that "transport=ws" is used for both WS and WSS. I've a >>>>>>>>> proxy server that receives an INVITE for a WSS destination, and >>>>>>>>> this proxy supports both WS and WSS. >>>>>>>>> This proxy server must have core parameter >>>>>>>>> tcp_connection_match=1 set, and this leads the t_relay() to fail. >>>>>>>>> When an INVITE comes, these are the steps. >>>>>>>>> - The URI is something like >>>>>>>>> >>> sip:user@anonymous.invalid;alias=198.51.100.10~52833~6;transport=ws. >>>>>>>>> - First handle_ruri_alias() removes the alias (which has ~6 in >>>>>>>>> it, for >>>>>>>>> wss) and sets the $du to something like >>>>>>>>> sip:198.51.100.10:52833;transport=ws. >>>>>>>>> - Then loose_route_preloaded() processes the Route header fields >>>>>>>>> and forces the outbound socket to the TLS websocket one. >>>>>>>>> - Then t_relay() fails to relay the INVITE and responds with 477 or 500. >>>>>>>>> >>>>>>>>> If, however, there's a non-TLS websocket connection open to the >>>>>>>>> proxy, the INVITE would be erroneously relayed over that (using >>>>>>>>> the wrong kamailio-side TCP port). >>>>>>>>> I can go deeper with testing if required. I wonder whether this is a bug. >>>>>>>>> >>>>>>>>> James >>>>>>>>> __________________________________________________________ >>>>>>>>> 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: >>>>>>> __________________________________________________________ >>>>>>> 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: >>>>>> -- >>>>>> Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- >>>>>> linkedin.com/in/miconda Kamailio Consultancy, Training and >>>>>> Development Services -- asipto.com Kamailio Advanced Training, >>>>>> October 8-10, 2024 -- asipto.com >>>>>> >>>> -- >>>> Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- >>>> linkedin.com/in/miconda Kamailio Consultancy, Training and Development >>>> Services -- asipto.com Kamailio Advanced Training, October 8-10, 2024 >>>> -- asipto.com >>>>