SIP Contact Header Issue When Using TLS
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@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@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
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@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@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Mon, Mar 31, 2014 at 3:15 PM, JP <jaykris@gmail.com> wrote:
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.
This is normal.
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.
This is strange. What was on the other side? nsCertType checking is largely deprecated (only OpenVPN uses it AFAIK). Typically the standard client and server OIDs are used instead: http://www.openssl.org/docs/apps/x509.html#CERTIFICATE_EXTENSIONS IIRC the FreeSWITCH gentls_cert script properly sets both client and server purpose, which is what you would expect because the cert is set on a per profile basis and depending on call direction any given profile can be a SIP UAS or SIP UAC. -- Kristian Kielhofner
This is normal.
Setting "transport=tls" for the dial string doesn't appear to be clearly documented anywhere. I tried this purely out of intuition since "transport=tcp" (which is documented) didn't seem to work. The two main resources I've been using are http://wiki.freeswitch.org/wiki/SIP_TLS and https://wiki.freeswitch.org/wiki/Sofia-SIP. If there are additional resources that cover this feature in more detail please let me know.
This is strange. What was on the other side?
Both endpoints are FreeSWITCH servers.
nsCertType checking is largely deprecated (only OpenVPN uses it AFAIK). Typically the standard client and server OIDs are used instead
I set the "tls-version" parameter to "tlsv1" in the SIP profiles of both FreeSWITCH servers. Do you recommend using something else?
IIRC the FreeSWITCH gentls_cert script properly sets both client and server purpose, which is what you would expect because the cert is set on a per profile basis and depending on call direction any given profile can be a SIP UAS or SIP UAC.
The script appears to have 3 options: generating the "root" CA signing cert (i.e. setup), generating a server cert (i.e. create_server), and a client cert (i.e. create_client). There is also a "create" option but this just appears to be doing the same thing as "create_server". As you point out, a given user agent can act as a UAC or UAS depending on the direction of the request. In my case, what appears to be happening is that the call gets setup completely over the same TCP connection requiring just one TLS handshake. However, when the hangup is initiated from the terminating end of the call, the FreeSWITCH that was previously fulfilling the role of the UAS during call setup is now acting as the UAC and tries to setup a second TCP/TLS connection for sending the BYE. Since it is configured with a server cert - that is, a cert generated using the "create_server" option - it appears to fail purpose validation when the UAS challenges it for its cert. -JP On Mon, Mar 31, 2014 at 12:28 PM, Kristian Kielhofner <kris@kriskinc.com>wrote:
On Mon, Mar 31, 2014 at 3:15 PM, JP <jaykris@gmail.com> wrote:
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.
This is normal.
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.
This is strange. What was on the other side?
nsCertType checking is largely deprecated (only OpenVPN uses it AFAIK). Typically the standard client and server OIDs are used instead:
http://www.openssl.org/docs/apps/x509.html#CERTIFICATE_EXTENSIONS
IIRC the FreeSWITCH gentls_cert script properly sets both client and server purpose, which is what you would expect because the cert is set on a per profile basis and depending on call direction any given profile can be a SIP UAS or SIP UAC.
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
JP
-
Kristian Kielhofner
-
Michael Jerris