[SR-Users] Problem with TLS
Julien Chavanton
jchavanton at gmail.com
Tue Jun 12 09:50:34 CEST 2018
Hi, the problem with SIPS URI scheme is not only about the Contact header
but record-route and other headers.
One option is to use TOPOS.
You can find more information here:
- PJSIP Ticket #1735: Check Contact/Record-Route header in a secure
dialog.
- https://issues.asterisk.org/jira/browse/ASTERISK-24646
<https://flowroute.atlassian.net/secure/AddComment%21default.jspa?id=19438>
https://tools.ietf.org/html/rfc5630#section-3.2
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, recommends how a UAS can make some checks
to validate the security. Additionally, the History-Info header
field [RFC4244] could be inspected for detecting retargeting from SIP
and SIPS. Retargeting from SIP to SIPS by a proxy is an issue
because it can leave the receiver of the request with the impression
that the request was delivered securely on each hop, while in fact,
it was not.
On Mon, Jun 11, 2018 at 5:58 AM, Arik Halperin <arik at mobilinq.io> wrote:
> Daniel Hello,
>
> Pasted below, 200 OK and Following ACK(Recorded at the client side via
> wireshark configured with private key)
>
>
> BR,
> Arik
>
>
> Session Initiation Protocol (200)
> Status-Line: SIP/2.0 200 OK
> Message Header
> Via: SIP/2.0/TLS 192.168.2.2:48182;received=82.
> 80.164.63;rport=33898;branch=z9hG4bKPjVppvYKQb4X5lJrYpod1wU
> N.j3KVLrEiT;alias
> Record-Route: <sips:10.168.10.227:5099;r2=on;lr=on;ftag=
> ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes>
> Record-Route: <sips:70.36.25.65:443;transport=tls;r2=on;lr=on;
> ftag=ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes>
> From: "number" <sips:17813000000 at XXXXXX.com>;tag=
> ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF
> To: <sips:1111111 at XXXXXX.com>;tag=7t2StmvUeNpQD
> Call-ID: yekcL-0b2PhpgdQo52l921tjX1Z8wErH
> CSeq: 10885 INVITE
> Contact: <sip:1111111 at 10.168.10.200:5080;transport=tls>
> User-Agent: FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~
> 987c9b9a2a~64bit
> Accept: application/sdp
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
> REGISTER, REFER, NOTIFY
> Require: timer
> Supported: timer, path, replaces
> Allow-Events: talk, hold, conference, refer
> Session-Expires: 1800;refresher=uac
> Content-Type: application/sdp
> Content-Disposition: session
> Content-Length: 1056
> Remote-Party-ID: "1111111" <sip:1111111 at XXXXXX.com>;
> party=calling;privacy=off;screen=no
> Message Body
> Session Description Protocol
> Session Description Protocol Version (v): 0
> Owner/Creator, Session Id (o): FreeSWITCH 1528683321
> 1528683322 IN IP4 70.36.25.66
> Session Name (s): FreeSWITCH
> Connection Information (c): IN IP4 70.36.25.66
> Time Description, active time (t): 0 0
> Session Attribute (a): msid-semantic: WMS
> V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K
> Media Description, name and address (m): audio 37680 RTP/SAVP
> 107 96
> Media Attribute (a): ice-ufrag:b6TC1SdbiQd6k5GL
> Media Attribute (a): ice-pwd:NtGGa3jbPjvwRLASIklz2oAa
> Media Attribute (a): candidate:5807878115 1 udp 659136
> 10.168.10.200 38056 typ host generation 0
> Media Attribute (a): candidate:5807878115 2 udp 659135
> 10.168.10.200 38057 typ host generation 0
> Media Attribute (a): ssrc:3542382753 cname:ASW42RxMaWauQHpe
> Media Attribute (a): ssrc:3542382753 msid:
> V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K a0
> Media Attribute (a): ssrc:3542382753 mslabel:
> V60mDk4CUtzxt4H5xDQPB48KjzMcYE1K
> Media Attribute (a): ssrc:3542382753 label:
> V60mDk4CUtzxt4H5xDQPB48KjzMcYE1Ka0
> Media Attribute (a): rtpmap:107 opus/48000/2
> Media Attribute (a): rtpmap:96 telephone-event/8000
> Media Attribute (a): fmtp:107 useinbandfec=1; minptime=10;
> maxptime=40
> Media Attribute (a): fmtp:96 0-16
> Media Attribute (a): sendrecv
> Media Attribute (a): rtcp:37681
> Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80
> inline:/KCNveJuRh5lQ+g3YWnyb2QwQhl0GgdmxtKAJ5G3
> Media Attribute (a): ptime:20
> Media Attribute (a): candidate:K6gXQsPK0KD4MsGa 1 UDP
> 2130706431 70.36.25.66 37680 typ host
> Media Attribute (a): candidate:K6gXQsPK0KD4MsGa 2 UDP
> 2130706430 70.36.25.66 37681 typ host
> Media Attribute (a): end-of-candidates
>
>
>
>
> 1201 272.987349 192.168.2.2 70.36.25.65 SIP
> 695 Request: ACK sip:1111111 at 10.168.10.200:5080;transport=tls |
> 1201
>
> Frame 1201: 695 bytes on wire (5560 bits), 695 bytes captured (5560 bits)
> on interface 0
> Ethernet II, Src: Htc_50:62:7b (ac:37:43:50:62:7b), Dst: 9a:01:a7:d9:66:64
> (9a:01:a7:d9:66:64)
> Internet Protocol Version 4, Src: 192.168.2.2, Dst: 70.36.25.65
> Transmission Control Protocol, Src Port: 48182, Dst Port: 443, Seq: 8791,
> Ack: 10303, Len: 629
> Secure Sockets Layer
> Session Initiation Protocol (ACK)
> Request-Line: ACK sip:1111111 at 10.168.10.200:5080;transport=tls SIP/2.0
> Message Header
> Via: SIP/2.0/TLS 192.168.2.2:48182;rport;branch=
> z9hG4bKPjFpv1IqHt9ON8nS6zOYuUZ5HxhNTDTBq7;alias
> Max-Forwards: 70
> From: "number" <sips:17813000000 at XXXXXXXX.com>;tag=
> ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF
> To: sips:1111111 at XXXXXXX.com;tag=7t2StmvUeNpQD
> Call-ID: yekcL-0b2PhpgdQo52l921tjX1Z8wErH
> CSeq: 10885 ACK
> Route: <sips:70.36.25.65:443;transport=tls;lr;r2=on;ftag=
> ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes>
> Route: <sips:10.168.10.227:5099;lr;r2=on;ftag=
> ZmXcXh6ReoLbMco46J0fCpKOHkUR1sWF;nat=yes>
> Content-Length: 0
>
>
> On 11 Jun 2018, at 13:32, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
>
> Hello,
>
> can you paste here the 200OK for INVITE sent out by kamailio and the ACK
> received by kamailio?
>
> Cheers,
> Daniel
>
> On 11.06.18 09:51, Arik Halperin wrote:
>
> Daniel, Thank you!
>
> You are right about this.
>
> I configured PJSIP not to check whether the contact contains SIPS.
>
> This solved the problem on one of my setups where I have one NIC that has
> a public IP.
>
> However on the original setup, the kamailio has one public IP and one
> private IP. In that setup, the ACK to the 200 OK is not forwarded over the
> private IP to the freeswitch. This only happens in TLS, when I work with
> TCP it works well. I believe it is somehow connected to the record route,
> and I’m looking into PJSIP to try to find the answer, but is there anything
> I could do in the kamailio?
>
> I have the same problems with other SIP clients(Bria for example)
>
>
> Thanks,
> Arik Halperin
>
> On 11 Jun 2018, at 9:43, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
>
> Hello,
>
> Kamailio is not involved in the issue reported here. Practically, pjsip
> expects sips: scheme in the contact URI, which was set by FreeSwitch in
> 200ok. Maybe there is an option that you have to turn on for FreeSwitch to
> use sips: scheme.
>
> Otherwise, you can try to replace sip with sips in kamailio config and do
> the reverse the other way.
>
> Cheers,
> Daniel
>
> On 05.06.18 06:56, Arik Halperin wrote:
>
> Hello,
>
> I’m using TLS
>
> After receiving 200OK from kamailio:
>
> r2voip.clear2voipdialer I/(NativeSdk_2_0) 1528174138320 PJSIP:
> (NativeSdk_2_0) 1528174138320 PJSIP:2018-05 07:48:58.319 pjsua_core.c RX
> 2203 bytes Response msg 200/INVITE/cseq=8107 (rdata0x7a2c56fb38) from TLS
> 70.36.25.65:443:
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/TLS 10.134.232.109:44097
> ;received=109.253.173.146;rport=31373;branch=z9hG4bKPj4MV5llP9SW5ufk-OcFB-
> Qh78PmIQFrRk;alias
>
> Record-Route: <sips:10.168.10.227:5099
> ;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes>
>
> Record-Route: <sips:70.36.25.65:443;
> transport=tls;r2=on;lr=on;ftag=mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO;nat=yes>
>
> From: "number" <sips:
> 972523391991 at XXXXXXX.com <972523391991 at kamprod.telemessage.com>>;tag=
> mgMLDFMLmCZGzcpASoODG8XgeFJVtcRO
>
> To: <sips:1111111 at XXXXXX.com
> <1111111 at kamprod.telemessage.com>>;tag=64H63g861ajHj
>
> Call-ID: Sq4jR85o3Caz2XTXo-
> 71FKAdbJ1x9vz2
>
> CSeq: 8107 INVITE
>
> Contact: <sip:1111111 at 10.168.10.200:
> 5080;transport=tls>
>
> User-Agent:
> FreeSWITCH-mod_sofia/1.6.20+git~20180123T214909Z~987c9b9a2a~64bit
>
> Accept: application/sdp
>
> Allow: INVITE, ACK, BYE, CANCEL,
> OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
>
> Require: timer
>
> Supported: ti
>
>
> *PJSIP responds with:*
>
> *Secure dialog requires SIPS scheme in Contact and Record-Route headers,
> ending the session*
>
> What is the reason for this? How can I fix this issue?
>
> Thanks,
> Arik Halperin
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
>
>
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
>
>
>
> _______________________________________________
> 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/20180612/3ccb9ac0/attachment.html>
More information about the sr-users
mailing list