[SR-Users] SSL Offloading with AWS ELB or Google GSLB and Kamailio
Joel Serrano
joel at textplus.com
Thu Oct 10 18:58:04 CEST 2019
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.safarov at 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 <joel at 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.work at gmail.com> wrote:
>>
>>> Out of curiosity, is this on AWS?
>>>
>>> On Wed, 9 Oct 2019 at 23:33, David Villasmil <
>>> david.villasmil.work at 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 <joel at 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:14a84f2016944eb0854ef0e9b71bfa10 at 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 at 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 at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>> --
>>>> Regards,
>>>>
>>>> David Villasmil
>>>> email: david.villasmil.work at gmail.com
>>>> phone: +34669448337
>>>>
>>> --
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.work at gmail.com
>>> phone: +34669448337
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20191010/691cf36a/attachment.html>
More information about the sr-users
mailing list