<div dir="ltr"><div dir="ltr">Hey Sergey, <br><div><br></div><div>In our use-case, we control all our clients (mobile app) and use SIP with transport=tls, never SIPS.</div><div><br></div><div>Also, in my initial tests, I see the Via headers OK, but the RR headers are the ones I might have to hack a little, as they are added with transport=tcp when in reality it should be transport=tls.</div><div><br></div><div>I was thinking (and will test later today) of using a manually built record-route...</div><div><br></div><div>Testing with something like:<br></div><div><br></div><div> if (is_method("INVITE")) {<br> record_route();<br> }<br></div><div><br></div><div>That adds transport=tcp (obviously as the received socket is TCP), so maybe using:</div><div><br></div><div> if (is_method("INVITE")) {<br> record_route(";transport=tls");<br> }<br></div></div><div><br></div><div>If that doesn't **replace** the current transport, and only appends it, (leaving the RR with 2 transport declarations) then I will try with:</div><div><br></div><div>record_route_preset("custom-inbound-RR", "custom-outbound-RR")</div><div><br></div><div><a href="https://kamailio.org/docs/modules/devel/modules/rr.html#rr.f.record_route_preset">https://kamailio.org/docs/modules/devel/modules/rr.html#rr.f.record_route_preset</a><br></div><div><br></div><div>I really don't know if this will work, but it might heh! <br></div><div><br></div><div>Let me know what you think and if you have any other ideas/suggestions.</div><div><br></div><div><br></div><div>Thanks, </div><div>Joel.</div><div><br></div><div><br></div><div><br></div><div>On Wed, Oct 9, 2019 at 8:38 PM Sergey Safarov <<a href="mailto:s.safarov@gmail.com">s.safarov@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Here important moment about "sips" URI supports.<br>That requires use of <a href="https://tools.ietf.org/html/rfc5630" target="_blank">rfc5630</a><div><br></div><div><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span style="line-height:0pt;display:inline;font-size:1em;font-weight:bold"><h4 style="line-height:0pt;display:inline;font-size:1em"><a name="m_2452739635713667436_section-3.1.3" href="https://tools.ietf.org/html/rfc5630#section-3.1.3" style="color:black;text-decoration-line:none" target="_blank">3.1.3</a>. Using TLS with SIP Instead of SIPS</h4></span>
Because a SIPS URI implies that requests sent to the resource
identified by it be sent over each SIP hop over TLS, SIPS URIs are
not suitable for "best-effort TLS": they are only suitable for "TLS-
only" requests. This is recognized in <a href="https://tools.ietf.org/html/rfc3261#section-26.2.2" target="_blank">Section 26.2.2 of [RFC3261]</a>.</pre></div><div><br></div><div><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span style="line-height:0pt;display:inline;font-size:1em;font-weight:bold"><h3 style="line-height:0pt;display:inline;font-size:1em"><a name="m_2452739635713667436_section-3.2" href="https://tools.ietf.org/html/rfc5630#section-3.2" style="color:black;text-decoration-line:none" target="_blank">3.2</a>. Detection of Hop-by-Hop Security</h3></span>
The presence of a SIPS Request-URI does not necessarily indicate that
the request was sent securely on each hop. So how does a UAS know if
SIPS was used for the entire request path to secure the request end-
to-end? Effectively, the UAS cannot know for sure. However,
<a href="https://tools.ietf.org/html/rfc3261#section-26.4.4" target="_blank">[RFC3261], Section 26.4.4</a>, recommends how a UAS can make some checks
to validate the security.</pre></div><div><br></div><div><a href="https://tools.ietf.org/html/rfc3261#section-26.4.4" target="_blank">rfc3261</a><br></div><div><br></div><div><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"> Ensuring that TLS will be used for all of the request segments up to
the target domain is somewhat complex. It is possible that
cryptographically authenticated proxy servers along the way that are
non-compliant or compromised may choose to disregard the forwarding
rules associated with SIPS (and the general forwarding rules in
<a href="https://tools.ietf.org/html/rfc3261#section-16.6" target="_blank">Section 16.6</a>). Such malicious intermediaries could, for example,
retarget a request from a SIPS URI to a SIP URI in an attempt to
downgrade security.</pre></div><div><br></div><div><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"> To address these concerns, it is RECOMMENDED that recipients of a
request whose Request-URI contains a SIP or SIPS URI inspect the To
header field value to see if it contains a SIPS URI (though note that
it does not constitute a breach of security if this URI has the same
scheme but is not equivalent to the URI in the To header field).
Although clients may choose to populate the Request-URI and To header
field of a request differently, when SIPS is used this disparity
could be interpreted as a possible security violation, and the
request could consequently be rejected by its recipient. Recipients
MAY also inspect the Via header chain in order to double-check
whether or not TLS was used for the entire request path until the
local administrative domain was reached. S/MIME may also be used by
the originating UAC to help ensure that the original form of the To
header field is carried end-to-end.</pre></div><div><br></div><div>IF this recommendation is applied, then you not able to establish SIPS call. Because TCP or TLS proto will be used in socket or in via headers.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 1:46 AM Joel Serrano <<a href="mailto:joel@textplus.com" target="_blank">joel@textplus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey David, <div><br></div><div>No, I was testing using the GSLB in GCP (Google) platform, but I believe the exact same scenario would either work (or not) on AWS, as at the end the key here is taking advantage of proxy protocol and SSL offloading, and both these cloud providers have that option.</div><div><br></div><div>I'm going to give a try using force socket, maybe that's the way to go, I'll report back what I find out.</div><div><br></div><div>Thanks!</div><div>Joel.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 9, 2019 at 3:37 PM David Villasmil <<a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">Out of curiosity, is this on AWS?</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Oct 2019 at 23:33, David Villasmil <<a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">It looks pretty clear to me. I think whenever kamailio “sees” that protocol specification it will switch to that. Have you tried forcing the socket? Just wondering whether that would work.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Oct 2019 at 20:33, Joel Serrano <<a href="mailto:joel@textplus.com" target="_blank">joel@textplus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone, <br><div><br></div><div>I was giving a try to setup Kamailio with a Cloud TCP load balancer in front, taking advantage of the newly added proxy protocol compatibility and my initial tests went very well.</div><div><br></div><div>Flow: client -> (tcp) -> load balancer -> (tcp) -> Kamailio TCP socket</div><div><br></div><div>I then did another quick test and enabled TLS, also with good results:</div><div><br></div><div><div>Flow: client -> (tls) -> load balancer -> (tls) -> Kamailio TLS socket</div><div><br></div><div>So far so good, proxy protocol works as expected.</div><div><br></div><div>I wanted to go one step further and see if I could somehow offload SSL operations at the load balancer level, and leave kamailio handling plain tcp.</div></div><div><br></div><div>Flow: client -> (tls) -> load balancer -> (tcp) -> Kamailio TCP socket</div><div><br></div><div>This partially worked, and before I start digging into what I have to do to get it completely working, I'd like to know if anyone already has a similar setup, or even if Kamailio is able to handle such a scenario, the reason I'm asking is because of the headers, etc.</div><div><br></div><div>In this last scenario, I receive in a TCP socket, a request with TLS headers all over the place..</div><div><br></div><div><pre style="box-sizing:inherit;margin-top:4px;margin-bottom:4px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;border-radius:4px;color:rgb(29,28,29);font-family:Monaco,Menlo,Consolas,"Courier New",monospace">INVITE <a href="http://sip:14a84f2016944eb0854ef0e9b71bfa10@app.mydomain.com:60655" target="_blank">sip:14a84f2016944eb0854ef0e9b71bfa10@app.mydomain.com:60655</a> SIP/2.0<br style="box-sizing:inherit">Via: SIP/2.0/TLS 192.168.1.16:60717;branch=z9hG4bK.KmUpamn5P;rport<br style="box-sizing:inherit">From: ...<br style="box-sizing:inherit">To: ...<br style="box-sizing:inherit">CSeq: 21 INVITE<br style="box-sizing:inherit">Call-ID: -j1QSnam9o<br style="box-sizing:inherit">Max-Forwards: 70<br style="box-sizing:inherit">Route: <sip:<a rel="noopener noreferrer" style="box-sizing:inherit;color:inherit;text-decoration-line:none">sbc-test2.mydomain.com:443;lr></a><br style="box-sizing:inherit">Supported: replaces, outbound<br style="box-sizing:inherit">Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE<br style="box-sizing:inherit">Content-Type: application/sdp<br style="box-sizing:inherit">Content-Length: 436<br style="box-sizing:inherit">Contact: <sip:linphone@A.B.C.D:60717;transport=tls>;+sip.instance="<urn:uuid:fabcb441-a348-49a7-948d-72448d6840eb>"</pre></div><div><br></div><div>I then forward this request via UDP to subsequent proxies for further processing, on the replies, my payload information back to the client should be TLS, although sent via a TCP socket..</div><div><br></div><div>Is this something that will not work by design? Is there any hack I can take advantage of?</div><div><br></div><div>The goal would be for Kamailio to handle TLS headers via TCP socket, as the client expects TLS information, but the actual traffic should go in plan TCP, and the load balancer will take care of re-encrypting before replying to the client.</div><div><br></div><div>Any ideas/suggestions/comments? </div><div><br></div><div>I hope this email is understandable, I find it complicated to detail the exact problem, feel free to ask any questions if you don't understand anything.</div><div><br></div><div>Thanks, </div><div>Joel.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>
</blockquote></div></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div></div>