---
title: "proto_tls module"
description: "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."
---

## Admin Guide


### 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.


### 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.


### 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.


### Dependencies


#### OpenSIPS Modules


The following modules must be loaded before this module:


- *tls_openssl* or *tls_wolfssl*,
				depending on the desired TLS library
- *tls_mgm*.


#### Dependencies of external libraries


The following libraries or applications must be installed before
		running OpenSIPS with this module loaded:


- *None*.


### Exported Parameters


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


#### 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.


```c title="Set listen variable"
...
socket= tls:1.2.3.4:5061
...
				
```


#### 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.*


```c title="Set tls_port variable"
...
modparam("proto_tls", "tls_port", 5062)
...
				
```


#### 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).*


```c title="Set tls_crlf_pingpong parameter"
...
modparam("proto_tls", "tls_crlf_pingpong", 0)
...
```


#### 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).*


```c title="Set tls_crlf_drop parameter"
...
modparam("proto_tls", "tls_crlf_drop", 1)
...
```


#### 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.*


```c title="Set tls_max_msg_chunks parameter"
...
modparam("proto_tls", "tls_max_msg_chunks", 8)
...
```


#### 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).*


```c title="Set cert_check_on_conn_reusage parameter"
...
modparam("proto_tls", "cert_check_on_conn_reusage", 1)
...
```


#### 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).*


```c title="Set trace_destination parameter"
...
modparam("proto_hep", "hep_id", "[hep_dest]10.0.0.2;transport=tcp;version=3")

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


#### trace_on (int)


This controls whether tracing for tls is on or not. You still need to define
			[tls trace destination](#param_trace_destination)in order to work, but this value will be
			controlled using mi function [mi tls trace](#mi_tls_trace).


```c title="Set trace_on parameter"
...
modparam("proto_tls", "trace_on", 1)
...
```


#### 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 [tls trace destination](#param_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](#param_trace_on) is
			set to 0 or tracing is deactived via the mi command [mi tls trace](#mi_tls_trace)
			this route won't be called.


```c title="Set trace_filter_route parameter"
...
modparam("proto_tls", "trace_filter_route", "tls_filter")
...
/* all tls connections will go through this route if tracing is activated
 * 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) == 5060)
		exit;
	else
		drop;
}
...
```


#### 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.*


```c title="Set tls_handshake_timeout variable"
...
modparam("proto_tls", "tls_handshake_timeout", 200) # number of milliseconds
...
```


#### 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.*


```c title="Set tls_send_timeout variable"
...
modparam("proto_tls", "tls_send_timeout", 200) # number of milliseconds
...
```


#### tls_async (integer)


If the TLS connect and write operations should be done in an
			asynchronous mode (non-blocking connect and
			write). If disabled, OpenSIPS will block and wait for TLS
			operations like connect and write.


*Default value is 1 (enabled).*


```c title="Set tls_async variable"
...
modparam("proto_tls", "tls_async", 1) # enable async TLS
...
```


#### tls_async_max_postponed_chunks (integer)


If *tls_async* is enabled, this specifies the
			maximum number of SIP messages that can be stashed for later/async
			writing. If the connection pending writes exceed this number, the
			connection will be marked as broken and dropped.


*Default value is 32.*


```c title="Set tls_async_max_postponed_chunks parameter"
...
modparam("proto_tls", "tls_async_max_postponed_chunks", 16)
...
```


#### tls_async_local_connect_timeout (integer)


If *tls_async* is enabled, this specifies the
			number of milliseconds that a connect will be tried in blocking
			mode (optimization). If the connect operation lasts more than
			this, the connect will go to async mode and will be passed to tls
			MAIN for polling.


*Default value is 100 ms.*


```c title="Set tls_async_local_connect_timeout parameter"
...
modparam("proto_tls", "tls_async_local_connect_timeout", 200)
...
```


#### tls_async_handshake_timeout (integer)


If *tls_async* is enabled, this specifies the
			number of milliseconds that a TLS handshake should be tried in blocking
			mode (optimization). If the handshake operation lasts more than this,
			the write will go to async mode and will be passed to tls MAIN for
			polling.


*Default value is 10 ms.*


```c title="Set tls_async_handshake_timeout parameter"
...
modparam("proto_tls", "tls_async_handshake_timeout", 100)
...
```


### Exported MI Functions


#### 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:


```c
			opensips-cli -x mi tls_trace on
			
```


## Developer Guide


### TLS_SERVER


#### SSL data per connection


Each TLS connection, incoming or outgoing, creates an
			SSL * object, where configuration inherited from the
			SSL_CTX * and particular info on that socket are stored.
			This SSL * structure is kept in OpenSIPS as  long as the connection
			is alive, as part of the "struct tcp_connection *"
			object:


```c
...
struct tcp_connection *c;
SSL *ssl;

/*create somehow SSL object*/
c->extra_data = (void *) ssl;
ssl = (SSL *) c->extra_data;
...
```


#### tls_print_errstack


void  tls_print_errstack(void);


Dumps ssl error stack.


#### tls_tcpconn_init


int tls_tcpconn_init( struct tcp_connection *c, int fd);


Called when new tcp connection is accepted


#### tls_tcpconn_clean


void tls_tcpconn_clean( struct tcp_connection *c);


Shuts down the TLS connection.


#### tls_blocking_write


size_t tls_blocking_write( struct tcp_connection *c, int fd,
			const char *buf, size_t len);


Writes a memory chunk in blocking mode (syncron).


#### tls_read


size_t tls_read( struct tcp_connection *c);


Reads from a TLS connection. Return the number of bytes read.


#### tls_fix_read_conn


void tls_tcpconn_clean( struct tcp_connection *c);


Shuts down the TLS connection.


## Frequently Asked Questions


**Q: Where can I post a question about TLS?**


Use one (the most appropriate) of the OpenSIPS mailing lists:

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


**Q: 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](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


**Q: 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.


**Q: 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.


**Q: Where can I find more about OpenSIPS?**


Take a look at [https://opensips.org/](https://opensips.org/).


**Q: 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:

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.


**Q: How can I report a bug?**


Please follow the guidelines provided at:
			[https://github.com/OpenSIPS/opensips/issues](https://github.com/OpenSIPS/opensips/issues).
<!-- CONTRIBUTORS -->

### License

All documentation files (i.e. .md extension) are licensed under the Creative Common License 4.0
