[asterisk-bugs] [JIRA] (ASTERISK-24646) PJSIP changeset 4899 breaks TLS

Sat Feb 21 13:49:34 CST 2015

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225048#comment-225048 ] 

Stephan Eisvogel commented on ASTERISK-24646:
---------------------------------------------

Not sure how to deal with closed tickets, but here it goes. I think I have identified another
scenario not fixed with this patch. I checked out SVN-branch-11-r432098M and the problem
does exist there still. I also tried revision r431423 to exclude possibility of introduced regression
since that patch, but it ain't. Scenario:

SIP phone (unencrypted) <---> Asterisk <---> Newer PJSIP client (encrypted, IP 192.168.129.114 in below example)

In sip.conf peer definitions only the pjsip client has the entries transport=tls and encryption=yes. The initiating SIP
phone on the left doesn't and therefore talks plaintext with Asterisk. Here is what happens on right side:

-----------------------------------------------------------------------------------------------------------------
Reliably Transmitting (NAT) to 192.168.129.114:53854:
INVITE sips:2004 at 192.168.129.114:53854;transport=TLS;ob SIP/2.0
Via: SIP/2.0/TLS 192.168.129.1:5061;branch=z9hG4bK6327ac34;rport
Max-Forwards: 70
From: "Test" <sip:2000 at 192.168.129.1>;tag=as49504738
To: <sips:2004 at 192.168.129.114:53854;transport=TLS;ob>
Contact: <sip:2000 at 192.168.129.1:5061;transport=TLS>
Call-ID: 0170dac0676a490200fee7c13f1b8609 at 192.168.129.1:5061
CSeq: 102 INVITE
Date: Sat, 21 Feb 2015 17:47:53 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 523
...

<--- SIP read from TLS:192.168.129.114:53854 --->
SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/TLS 192.168.129.1:5061;rport=5061;received=192.168.129.1;branch=z9hG4bK6327ac34
Call-ID: 0170dac0676a490200fee7c13f1b8609 at 192.168.129.1:5061
From: "Test" <sip:2000 at 192.168.129.1>;tag=as49504738
To: <sips:2004 at 192.168.129.114;ob>;tag=z9hG4bK6327ac34
CSeq: 102 INVITE
Warning: 381 localhost "SIPS Required"
Content-Length: 0

Transmitting (NAT) to 192.168.129.114:53854:
ACK sips:2004 at 192.168.129.114:53854;transport=TLS;ob SIP/2.0
Via: SIP/2.0/TLS 192.168.129.1:5061;branch=z9hG4bK6327ac34;rport
Max-Forwards: 70
From: "Test" <sip:2000 at 192.168.129.1>;tag=as49504738
To: <sips:2004 at 192.168.129.114:53854;transport=TLS;ob>;tag=z9hG4bK6327ac34
Contact: <sip:2000 at 192.168.129.1:5061;transport=TLS>
Call-ID: 0170dac0676a490200fee7c13f1b8609 at 192.168.129.1:5061
CSeq: 102 ACK
Content-Length: 0
-----------------------------------------------------------------------------------------------------------------

In the very first invite, the line Contact: <sip:2000 at 192.168.129.1:5061;transport=TLS> is
imho the problem. Asterisk fails to determine if called party requires TLS and does not set
contact header of invite packet to sips if that's the case.

> PJSIP changeset 4899 breaks TLS
> -------------------------------
>
>                 Key: ASTERISK-24646
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24646
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 11.15.0
>         Environment: Linux; hostile
>            Reporter: Stephan Eisvogel
>            Assignee: Mark Michelson
>      Target Release: 11.16.0, 13.2.0
>
>         Attachments: ASTERISK-24646-chan_sip.patch, ASTERISK-24646.patch, sip-trace.txt
>
>
> PJSIP as of changeset 4899 (https://trac.pjsip.org/repos/changeset/4899) has started verifying the Contact-header sent by the server to be of the SIPS scheme if transport is TLS. It will not check the Contact-header for ";transport=TLS" as sent by Asterisk.
> As a result, registration by a client using this well-known stack will succeed, but any call attempt will terminate. A SIP trace will show the message "Warning: 381 localhost SIPS Required" going from the client to the server.
> This was found using CSipSimple-trunk, other clients e.g. MicroSIP will likely follow, once this change has crept into their code bases.
> The issue has previously been discussed last year here http://lists.digium.com/pipermail/asterisk-dev/2013-September/062567.html Asterisk developers were of the opinion that using SIPS in Contact-header will break proxying up a chain. PJSIP developers seem to be of the opinion they are following RFCs. And I am puzzled, looking for a resolution.
> Workarounds/fixes I could identify:
> 1. Set disable_secure_dlg_check = PJ_TRUE on clients using PJSIP
> 2. Modify PJSIP's pjsip_inv_verify_request3 to check for ;transport=TLS not only in Record-Route-header but also in Contact-header.
> 3. Patch Asterisk to emit SIPS scheme when transport is TLS
> I suggest identifying first, if this should be an Asterisk issue at all, or be brought up with PJSIP developers to change the default behaviour.

--
This message was sent by Atlassian JIRA
(v6.2#6252)