proto_tls module
     __________________________________________________________

   Table of Contents

   1. Admin Guide

        1.1. Overview
        1.2. History
        1.3. Scenario
        1.4. Dependencies

              1.4.1. OpenSIPS Modules
              1.4.2. Dependencies of external libraries

        1.5. OpenSIPS Exported parameters

              1.5.1. listen=interface
              1.5.2. tls_port (integer)
              1.5.3. tls_crlf_pingpong (integer)
              1.5.4. tls_crlf_drop (integer)
              1.5.5. tls_max_msg_chunks (integer)
              1.5.6. cert_check_on_conn_reusage (integer)
              1.5.7. trace_destination (string)
              1.5.8. trace_on (int)
              1.5.9. trace_filter_route (string)
              1.5.10. tls_handshake_timeout (integer)
              1.5.11. tls_send_timeout (integer)

        1.6. Exported MI Functions

              1.6.1. tls_trace

   2. Frequently Asked Questions
   3. Contributors

        3.1. By Commit Statistics
        3.2. By Commit Activity

   4. Documentation

        4.1. Contributors

   List of Tables

   3.1. Top contributors by DevScore^(1), authored commits^(2) and
          lines added/removed^(3)

   3.2. Most recently active contributors^(1) to this module

   List of Examples

   1.1. Set listen variable
   1.2. Set tls_port variable
   1.3. Set tls_crlf_pingpong parameter
   1.4. Set tls_crlf_drop parameter
   1.5. Set tls_max_msg_chunks parameter
   1.6. Set cert_check_on_conn_reusage parameter
   1.7. Set trace_destination parameter
   1.8. Set trace_on parameter
   1.9. Set trace_filter_route parameter
   1.10. Set tls_handshake_timeout variable
   1.11. Set tls_send_timeout variable

Chapter 1. Admin Guide

1.1. Overview

   TLS, as defined in SIP RFC 3261, is a mandatory feature for
   proxies and can be used to secure the SIP signalling on a
   hop-by-hop basis (not end-to-end). TLS works on top of TCP.
   DTLS, or TLS over UDP is already defined by IETF and may become
   available in the future.

1.2. History

   The TLS support was originally developed by Peter Griffiths and
   posted as a patch on SER development mailing list. Thanks to
   Cesc Santasusana, several problems were fixed and some
   improvements were added.

   The TLS support was simultaneously added in both projects. In
   SER, the support was committed in a separate “experimental” CVS
   tree, as patch to the main CVS tree. In OpenSIPS, the support
   was integrated directly into the CVS tree, as a built-in
   component, and is part of stable OpenSIPS since release
   >=1.0.0.

   Starting with OpenSIPS 2.1, the TLS has been moved to a
   separate transport module, that implements the more generic
   Transport Interface.

1.3. Scenario

   By the increased number of providers the SIP world is
   continuously growing. More users means more calls and more
   calls means a high probability for a user to receive calls from
   totally unknown people or, in the worst case, to receive
   unwanted calls. To prevent this, a defense mechanism must be
   adopted by the SIP provider. Since only the called user is
   fully able to classify a call as being unwanted, the SIP
   server, based on all information regarding the call should
   notify the user about the desirability of the call. Information
   like the caller domain, the received source or the incoming
   protocol can be very useful for a SIP server to establish the
   nature of the call.

   As this information is quite limited, is very improbable for a
   server to be able detect the unwanted calls - there are many
   calls that it cannot predict anything about its status (neutral
   calls). So, instead on alerting the called user about unwanted
   calls, the server can notify the user about calls that are
   considered trusted - calls for which the server is 100% sure
   there are not unwanted.

   So, a trust concept must be defined for SIP servers. Which
   calls are trusted and which are not? A call is trusted if the
   caller can be identify as a trustable user - a user about we
   have reliable information.

   Since all the user from its domain are authenticated (or should
   be), a SIP server can consider all the calls generated by its
   user as trusted. Now we have to extend the trust concept to the
   multi-domain level. A mutual agreement, between several
   domains, can establish a trusting relationship. So, a domain
   (called A) will consider also as trusted calls all the calls
   generated by user from a different domain (called B) and
   vice-versa. But just an agreement is not enough; since the
   authentication information is strictly limited to a domain (a
   domain can authenticate only its own user, not the user from
   other domains), there is still the problem of checking the
   authenticity of the caller - he can impersonate (by a false
   FROM header) a user from a domain that is trusted.

   The answer to this problem is TLS (Transport Layer Security).
   All calls via domain A and domain B will be done via TLS.
   Authentication in origin domain plus TLS transport between
   domains will make the call 100% trusted for the target domain.

   For such a mechanism to work, the following requirements must
   be met:
     * all UA must have set as outbound proxy their home server.
     * all SIP servers must authenticated all the calls generated
       by their own users.
     * all SIP servers must relay the calls generated be their
       user to a trusted domain via TLS.

   Based on this, a server can classify as trusted a call for one
   of its user only if the call is also generated by one of its
   users or is the call is received from a trusted domain ( which
   is equivalent with a call received via TLS). Untrusted call
   will be calls received from users belonging to untrusted
   domains or from users from trusted domains, but whose calls are
   not routed via their home server (so, they are not
   authenticated by there home servers).

   Once the server is able to tell if the call is trusted or not,
   the still open issue is about the mechanism used by server to
   notify the called user about the nature of the incoming call.

   One way to do it is by remotely changing the ringing type of
   the called user's phone. This can be done by inserting special
   header into the INVITE request. Such feature is supported by
   now by several hardphones like CISCO ATA, CISCO 7960 and SNOM.
   This phones can change their ringing tone based on the present
   or content of the "Alert-Info" SIP header as follows:
     * CISCO ATA - it has 4 pre-defined ringing types. The
       Alert-Info header must look like “Alert-info: Bellcore-drX
       EOH” where X can be between 1 and 4. Note that 1 is the
       phone default ringing tone.
     * CISCO 7960 - it has 2 pre-defined ringing types and the
       possibility of uploading new ones. The “Alert-Info” header
       must look like “Alert-info: X EOH” where X can be whatever
       number. When this header is present, the phones will not
       change the ringing tone, but the ringing pattern. Normally,
       the phone rings like [ring.........ring..........ring]
       where [ring] is the ringing tone; if the header is present,
       the ringing pattern will be
       [ring.ring.........ring.ring........]. So, to be able to
       hear some difference between the two patterns (and not only
       as length), its strongly recommended to have a highly
       asymmetric ringing type (as the pre-defined are not!!).
     * SNOM - The “Alert-Info” header must look like “Alert-info:
       URL EOH"” where URL can be a HTTP URL (for example) from
       where the phone can retrieve a ringing tone.

1.4. Dependencies

1.4.1. OpenSIPS Modules

   The following modules must be loaded before this module:
     * tls_mgm.

1.4.2. Dependencies of external libraries

   OpenSIPS TLS v1.0 support requires the following packages:
     * openssl or libssl >= 0.9.6
     * openssl-dev or libssl-dev

   OpenSIPS TLS v1.1/1.2 support requires the following packages:
     * openssl or libssl >= 1.0.1e
     * openssl-dev or libssl-dev

1.5. OpenSIPS Exported parameters

   All these parameters can be used from the opensips.cfg file, to
   configure the behavior of OpenSIPS-TLS.

1.5.1. listen=interface

   Not specific to TLS. Allows to specify the protocol (udp, tcp,
   tls), the IP address and the port where the listening server
   will be.

   Example 1.1. Set listen variable
...
socket= tls:1.2.3.4:5061
...

1.5.2. tls_port (integer)

   The default port to be used for all TLS related operation. Be
   careful as the default port impacts both the SIP listening part
   (if no port is defined in the TLS listeners) and the SIP
   sending part (if the destination URI has no explicit port).

   If you want to change only the listening port for TLS, use the
   port option in the SIP listener defintion.

   Default value is 5061.

   Example 1.2. Set tls_port variable
...
modparam("proto_tls", "tls_port", 5062)
...

1.5.3. tls_crlf_pingpong (integer)

   Send CRLF pong (\r\n) to incoming CRLFCRLF ping messages over
   TLS. By default it is enabled (1).

   Default value is 1 (enabled).

   Example 1.3. Set tls_crlf_pingpong parameter
...
modparam("proto_tls", "tls_crlf_pingpong", 0)
...

1.5.4. tls_crlf_drop (integer)

   Drop CRLF (\r\n) ping messages. When this parameter is enabled,
   the TLS layer drops packets that contains a single CRLF
   message. If a CRLFCRLF message is received, it is handled
   according to the tls_crlf_pingpong parameter.

   Default value is 0 (disabled).

   Example 1.4. Set tls_crlf_drop parameter
...
modparam("proto_tls", "tls_crlf_drop", 1)
...

1.5.5. tls_max_msg_chunks (integer)

   The maximum number of chunks that a SIP message is expected to
   arrive via TLS. If a packet is received more fragmented than
   this, the connection is dropped (either the connection is very
   overloaded and this leads to high fragmentation - or we are the
   victim of an ongoing attack where the attacker is sending the
   traffic very fragmented in order to decrease server
   performance).

   Default value is 4.

   Example 1.5. Set tls_max_msg_chunks parameter
...
modparam("proto_tls", "tls_max_msg_chunks", 8)
...

1.5.6. cert_check_on_conn_reusage (integer)

   This parameter turns on or off the extra checking/matching of
   the TLS domain (SSL certificate) when comes to reusing an
   existing TLS connection. Without this extra check, only IP and
   port of the connections will be check (in order to re-use an
   existing connection). With this extra check, the connection to
   be reused must have the same SSL certificate as the one set for
   the current signaling operation.

   This checking is done only when comes to send SIP traffic via
   TLS and it is applied only against connections that were
   created / initiated by OpenSIPS (as TLS client). Any accepte
   connection (as TLS server) will automatically match (the extra
   test will be skipped).

   Default value is 0 (disabled).

   Example 1.6. Set cert_check_on_conn_reusage parameter
...
modparam("proto_tls", "cert_check_on_conn_reusage", 1)
...

1.5.7. trace_destination (string)

   Trace destination as defined in the tracing module. Currently
   the only tracing module is proto_hep. Network events such as
   connect, accept and connection closed events shall be traced
   along with errors that could appear in the process. For each
   connection that is created an event containing information
   about the client and server certificates, master key and
   network layer information shall be sent.

   WARNING: A tracing module must be loaded in order for this
   parameter to work. (for example proto_hep).

   Default value is none(not defined).

   Example 1.7. Set trace_destination parameter
...
modparam("proto_hep", "trace_destination", "[hep_dest]10.0.0.2;transport
=tcp;version=3")

modparam("proto_tls", "trace_destination", "hep_dest")
...

1.5.8. trace_on (int)

   This controls whether tracing for tls is on or not. You still
   need to define trace_destinationin order to work, but this
   value will be controlled using mi function tls_trace.
   Default value is 0(tracing inactive).

   Example 1.8. Set trace_on parameter
...
modparam("proto_tls", "trace_on", 1)
...

1.5.9. trace_filter_route (string)

   Define the name of a route in which you can filter which
   connections will be trace and which connections won't be. In
   this route you will have information regarding source and
   destination ips and ports for the current connection. To
   disable tracing for a specific connection the last call in this
   route must be drop, any other exit mode resulting in tracing
   the current connection ( of course you still have to define a
   trace_destination and trace must be on at the time this
   connection is opened.

   IMPORTANT Filtering on ip addresses and ports can be made using
   $si and $sp for matching either the entity that is connecting
   to OpenSIPS or the entity to which OpenSIPS is connecting. The
   name might be misleading ( $si meaning the source ip if you
   read the docs) but in reality it is simply the socket other
   than the OpenSIPS socket. In order to match OpenSIPS interface
   (either the one that accepted the connection or the one that
   initiated a connection) $socket_in(ip) (ip) and
   $socket_in(port) (port) can be used.

   WARNING: IF trace_on is set to 0 or tracing is deactived via
   the mi command tls_trace this route won't be called.
   Default value is none(no route is set).

   Example 1.9. Set trace_filter_route parameter
...
modparam("proto_tls", "trace_filter_route", "tls_filter")
...
/* all tls connections will go through this route if tracing is activate
d
 * and a trace destination is defined */
route[tls_filter] {
        ...
        /* all connections opened from/by ip 1.1.1.1:8000 will be traced
           on interface 1.1.1.10:5060(opensips listener)
           all the other connections won't be */
         if ( $si == "1.1.1.1" && $sp == 8000 &&
                $socket_in(ip) == "1.1.1.10"  && $socket_in(port) == 506
0)
                exit;
        else
                drop;
}
...

1.5.10. tls_handshake_timeout (integer)

   Sets the timeout (in milliseconds) for the SSL handshake
   sequence to complete. It may be necessary to increase this
   value when using a CPU intensive cipher for the connection to
   allow time for keys to be generated and processed.

   The timeout is invoked during acceptance of a new connection
   (inbound) and during the wait period when a new session is
   being initiated (outbound).

   Default value is 100.

   Example 1.10. Set tls_handshake_timeout variable

param("proto_tls", "tls_handshake_timeout", 200) # number of millisecond
s


1.5.11. tls_send_timeout (integer)

   Sets the timeout (in milliseconds) for the send operations to
   complete

   The send timeout is invoked for all TLS write operations,
   excluding the handshake process (see: tls_handshake_timeout)

   Default value is 100.

   Example 1.11. Set tls_send_timeout variable

param("proto_tls", "tls_send_timeout", 200) # number of milliseconds


1.6. Exported MI Functions

1.6.1.  tls_trace

   Name: tls_trace

   Parameters:
     * trace_mode(optional): set tls tracing on and off. This
       parameter can be missing and the command will show the
       current tracing status for this module( on or off );
       Possible values:
          + on
          + off

   MI FIFO Command Format:
                        opensips-cli -x mi tls_trace on

Chapter 2. Frequently Asked Questions

   2.1.

       Where can I post a question about TLS?

       Use one (the most appropriate) of the OpenSIPS mailing lists:
         * User Mailing List -
           http://lists.opensips.org/cgi-bin/mailman/listinfo/users
         * Developer Mailing List -
           http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

       Remember: first at all, check if your question wasn't already
       answered.

   2.2.

       How can I report a bug?

       Accumulate as much as possible information (OpenSIPS version,
       opensips -V output, your OS (uname -a), OpenSIPS logs, network
       dumps, core dump files, configuration file) and send a mail to
       http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

       Also you may try OpenSIPS's bug report web page:
       https://opensips.org/pmwiki.php?n=Development.Tracker

   2.3.

       How can I debug ssl/tls problems?

       Increase the log level in opensips.cfg (log_level=4) and watch
       the log statements in syslog.

       Install the ssldump utility and start it. This will give you a
       trace of the ssl/tls connections.

   2.4.

       What is the difference between the TLS directory and the TLSOPS
       module directory?

       The code in the TLS directory implements the TLS transport
       layer. The TLSOPS module implements TLS related functions which
       can be used in the routing script.

   2.5.

       Where can I find more about OpenSIPS?

       Take a look at https://opensips.org/.

   2.6.

       Where can I post a question about this module?

       First at all check if your question was already answered on one
       of our mailing lists:
         * User Mailing List -
           http://lists.opensips.org/cgi-bin/mailman/listinfo/users
         * Developer Mailing List -
           http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

       E-mails regarding any stable OpenSIPS release should be sent to
       <users@lists.opensips.org> and e-mails regarding development
       versions should be sent to <devel@lists.opensips.org>.

       If you want to keep the mail private, send it to
       <users@lists.opensips.org>.

   2.7.

       How can I report a bug?

       Please follow the guidelines provided at:
       https://github.com/OpenSIPS/opensips/issues.

Chapter 3. Contributors

3.1. By Commit Statistics

   Table 3.1. Top contributors by DevScore^(1), authored
   commits^(2) and lines added/removed^(3)
     Name DevScore Commits Lines ++ Lines --
   1. Bogdan-Andrei Iancu (@bogdan-iancu) 56 29 1543 809
   2. Razvan Crainea (@razvancrainea) 43 26 626 641
   3. Eseanu Marius Cristian (@eseanucristian) 41 5 55 2133
   4. Ionut Ionita (@ionutrazvanionita) 35 14 1232 576
   5. Liviu Chircu (@liviuchircu) 10 7 30 105
   6. Vlad Patrascu (@rvlad-patrascu) 8 5 53 63
   7. Bogdan Chifor 5 2 141 1
   8. Vlad Paiu (@vladpaiu) 4 2 84 3
   9. Dan Pascu (@danpascu) 3 1 2 4
   10. Julián Moreno Patiño 3 1 1 1

   All remaining contributors: Peter Lemenkov (@lemenkov), Zero
   King, Maksym Sobolyev (@sobomax).

   (1) DevScore = author_commits + author_lines_added /
   (project_lines_added / project_commits) + author_lines_deleted
   / (project_lines_deleted / project_commits)

   (2) including any documentation-related commits, excluding
   merge commits. Regarding imported patches/code, we do our best
   to count the work on behalf of the proper owner, as per the
   "fix_authors" and "mod_renames" arrays in
   opensips/doc/build-contrib.sh. If you identify any
   patches/commits which do not get properly attributed to you,
   please submit a pull request which extends "fix_authors" and/or
   "mod_renames".

   (3) ignoring whitespace edits, renamed files and auto-generated
   files

3.2. By Commit Activity

   Table 3.2. Most recently active contributors^(1) to this module
                      Name                   Commit Activity
   1.  Bogdan-Andrei Iancu (@bogdan-iancu) Feb 2015 - Apr 2020
   2.  Zero King                           Mar 2020 - Mar 2020
   3.  Dan Pascu (@danpascu)               Jan 2020 - Jan 2020
   4.  Razvan Crainea (@razvancrainea)     Feb 2015 - Jan 2020
   5.  Liviu Chircu (@liviuchircu)         Mar 2015 - May 2019
   6.  Vlad Patrascu (@rvlad-patrascu)     May 2017 - Nov 2018
   7.  Peter Lemenkov (@lemenkov)          Jun 2018 - Jun 2018
   8.  Maksym Sobolyev (@sobomax)          Jul 2017 - Jul 2017
   9.  Ionut Ionita (@ionutrazvanionita)   Mar 2015 - Apr 2017
   10. Julián Moreno Patiño                Feb 2016 - Feb 2016

   All remaining contributors: Eseanu Marius Cristian
   (@eseanucristian), Bogdan Chifor, Vlad Paiu (@vladpaiu).

   (1) including any documentation-related commits, excluding
   merge commits

Chapter 4. Documentation

4.1. Contributors

   Last edited by: Bogdan-Andrei Iancu (@bogdan-iancu), Zero King,
   Razvan Crainea (@razvancrainea), Liviu Chircu (@liviuchircu),
   Peter Lemenkov (@lemenkov), Vlad Patrascu (@rvlad-patrascu),
   Ionut Ionita (@ionutrazvanionita), Eseanu Marius Cristian
   (@eseanucristian), Vlad Paiu (@vladpaiu).

   Documentation Copyrights:

   Copyright © 2015 www.opensips-solutions.com

   Copyright © 2013 Secusmart GmbH

   Copyright © 2006 enum.at

   Copyright © 2005 Voice Sistem SRL

   Copyright © 2005 Cesc Santasusana
