Hey Sergey,

In our use-case, we control all our clients (mobile app) and use SIP with
transport=tls, never SIPS.

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.

I was thinking (and will test later today) of using a manually built
record-route...

Testing with something like:

    if (is_method("INVITE")) {
        record_route();
    }

That adds transport=tcp (obviously as the received socket is TCP), so maybe
using:

    if (is_method("INVITE")) {
        record_route(";transport=tls");
    }

If that doesn't **replace** the current transport, and only appends it,
(leaving the RR with 2 transport declarations) then I will try with:

record_route_preset("custom-inbound-RR", "custom-outbound-RR")

https://kamailio.org/docs/modules/devel/modules/rr.html#rr.f.record_route_preset

I really don't know if this will work, but it might heh!

Let me know what you think and if you have any other ideas/suggestions.


Thanks,
Joel.



On Wed, Oct 9, 2019 at 8:38 PM Sergey Safarov <s.safa...@gmail.com> wrote:

> Here important moment about "sips" URI supports.
> That requires use of rfc5630 <https://tools.ietf.org/html/rfc5630>
>
> 3.1.3 <https://tools.ietf.org/html/rfc5630#section-3.1.3>.  Using TLS with 
> SIP Instead of SIPS
>
>    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 Section 26.2.2 of [RFC3261] 
> <https://tools.ietf.org/html/rfc3261#section-26.2.2>.
>
>
> 3.2 <https://tools.ietf.org/html/rfc5630#section-3.2>.  Detection of 
> Hop-by-Hop Security
>
>    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,
>    [RFC3261], Section 26.4.4 
> <https://tools.ietf.org/html/rfc3261#section-26.4.4>, recommends how a UAS 
> can make some checks
>    to validate the security.
>
>
> rfc3261 <https://tools.ietf.org/html/rfc3261#section-26.4.4>
>
>    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
>    Section 16.6 <https://tools.ietf.org/html/rfc3261#section-16.6>).  Such 
> malicious intermediaries could, for example,
>    retarget a request from a SIPS URI to a SIP URI in an attempt to
>    downgrade security.
>
>
>    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.
>
>
> 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.
>
> On Thu, Oct 10, 2019 at 1:46 AM Joel Serrano <j...@textplus.com> wrote:
>
>> Hey David,
>>
>> 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.
>>
>> 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.
>>
>> Thanks!
>> Joel.
>>
>>
>>
>>
>> On Wed, Oct 9, 2019 at 3:37 PM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>>> Out of curiosity, is this on AWS?
>>>
>>> On Wed, 9 Oct 2019 at 23:33, David Villasmil <
>>> david.villasmil.w...@gmail.com> wrote:
>>>
>>>> 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.
>>>>
>>>> On Wed, 9 Oct 2019 at 20:33, Joel Serrano <j...@textplus.com> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> 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.
>>>>>
>>>>> Flow: client -> (tcp) -> load balancer -> (tcp) -> Kamailio TCP socket
>>>>>
>>>>> I then did another quick test and enabled TLS, also with good results:
>>>>>
>>>>> Flow: client -> (tls) -> load balancer -> (tls) -> Kamailio TLS socket
>>>>>
>>>>> So far so good, proxy protocol works as expected.
>>>>>
>>>>> 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.
>>>>>
>>>>> Flow: client -> (tls) -> load balancer -> (tcp) -> Kamailio TCP socket
>>>>>
>>>>> 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.
>>>>>
>>>>> In this last scenario, I receive in a TCP socket, a request with TLS
>>>>> headers all over the place..
>>>>>
>>>>> INVITE sip:14a84f2016944eb0854ef0e9b71bf...@app.mydomain.com:60655 SIP/2.0
>>>>> Via: SIP/2.0/TLS 192.168.1.16:60717;branch=z9hG4bK.KmUpamn5P;rport
>>>>> From: ...
>>>>> To: ...
>>>>> CSeq: 21 INVITE
>>>>> Call-ID: -j1QSnam9o
>>>>> Max-Forwards: 70
>>>>> Route: <sip:sbc-test2.mydomain.com:443;lr>
>>>>> Supported: replaces, outbound
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, 
>>>>> SUBSCRIBE, INFO, UPDATE
>>>>> Content-Type: application/sdp
>>>>> Content-Length: 436
>>>>> Contact: 
>>>>> <sip:linphone@A.B.C.D:60717;transport=tls>;+sip.instance="<urn:uuid:fabcb441-a348-49a7-948d-72448d6840eb>"
>>>>>
>>>>>
>>>>> 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..
>>>>>
>>>>> Is this something that will not work by design? Is there any hack I
>>>>> can take advantage of?
>>>>>
>>>>> 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.
>>>>>
>>>>> Any ideas/suggestions/comments?
>>>>>
>>>>> 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.
>>>>>
>>>>> Thanks,
>>>>> Joel.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users@lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>> --
>>>> Regards,
>>>>
>>>> David Villasmil
>>>> email: david.villasmil.w...@gmail.com
>>>> phone: +34669448337
>>>>
>>> --
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.w...@gmail.com
>>> phone: +34669448337
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to