[Freeswitch-users] SIP Contact Header Issue When Using TLS

[JP]

This is what I had to do to get TLS working for  me...


In order to get client authenticated TLS to work between 2 FreeSWITCH
servers, I had to add a "transport=tls" parameter to the dial string of the
outbound call:



            ex.  sofia/sip-ua/sips:10.191.210.23:5081;transport=tls



Without this parameter, the UAC does not add a "transport=tls" parameter to
the contact address of its initial INVITE request.  This seems to cause the
UAS to try to send all its subsequent requests (such as a BYE) over UDP
instead of TLS.



Also, generating the public certificate and private key store files using
FreeSWITCH's "gentls_cert" script as described in "
http://wiki.freeswitch.org/wiki/SIP_TLS" won't work by default for client
authenticated TLS.  This is because the script generates the certs with
attributes making them specific for either the server side or client side
of a TLS handshake.  The TLS handshake will fail Purpose Validation if you
try to configure a UAC with a cert that was generated specifically for a
server.  To get around this, I had to comment out the "nsCertType" and
"extendedKeyUsage" attributes from the "gentls_cert" script.


-JP


On Tue, Mar 25, 2014 at 5:05 PM, JP <jaykris at gmail.com> wrote:

> Do you mean to say that the UAC need only send to
> "sip:<ip>:<tls_port>;transport=tcp" and not to "sips"?
>
> I tried tweaking the parameters you mentioned in several different ways,
> but the contact address from the UAS always comes with "transport=udp".  Is
> this my problem?
>
>
> On Tue, Mar 25, 2014 at 10:22 AM, Michael Jerris <mike at jerris.com> wrote:
>
>> sips: should not make a difference, however.. take a look at bind-params
>> and tls-bind-params
>>
>> https://wiki.freeswitch.org/wiki/Sofia.conf.xml
>>
>> On Mar 25, 2014, at 1:15 PM, JP <jaykris at gmail.com> wrote:
>>
>> Is there any way to specify the full contact header in a UA profile that
>> the SIP stack will use when formulating messages?  Specifically, have it
>> use "sips" instead of "sip" as the protocol scheme?
>>
>>
>> I'm trying to establish an INVITE dialog between 2 FreeSWITCH servers
>> using a client authenticated TLS handshake.
>>
>>
>> To accomplish this, I've created 2 UA profiles on both servers - one to
>> fulfill the role of the UAC (i.e. tls-uac.xml) and one to implement the UAS
>> (i.e. tls-uas.xml).  Here are the relevant parameters from both profiles:
>>
>>
>> tls-uac.xml:
>>
>>
>>             <param name="sip-port" value="5081"/>
>>
>>
>>             <param name="tls" value="true"/>
>>
>>
>>             <param name="tls-only" value="true"/>
>>
>>
>>             <param name="tls-sip-port" value="5082"/>
>>
>>
>>             <param name="tls-cert-dir" value="$${base_dir}/conf/tls/uac"/>
>>
>>
>> tls-uas.xml:
>>
>>
>>             <param name="sip-port" value="5081"/>
>>
>>
>>             <param name="tls" value="true"/>
>>
>>
>>             <param name="tls-only" value="true"/>
>>
>>
>>             <param name="tls-sip-port" value="5081"/>
>>
>>
>>             <param name="tls-cert-dir" value="$${base_dir}/conf/tls/uas"/>
>>
>>
>> The problem already starts when "tls-uac" sends a non-secure SIP URI in
>> the contact header of its initial INVITE request (i.e.
>> sip:mod_sofia at 10.191.210.150:5081).  But the more immediate issue is
>> that "tls-uas" also responds with a non-secure SIP URI in the contact
>> header of its final response (i.e.
>> sip:14086805675 at 10.191.210.151:5081;transport=udp).  This causes
>> "tls-uac" to send its ACK to the right port number (i.e. 5081) but on the
>> wrong transport (i.e. UDP instead of TCP/TLS).
>>
>>
>> I've seen in the FS documentation that there are ways to manipulate the
>> contact header through the dial plan, but I'd really prefer not to do it
>> this way.  Any suggestions?
>>
>>
>> Thanks
>>
>> JP
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140331/f345a79c/attachment-0001.html