SIP Signaling over TLS Overview

The 2020 IMG supports TLS (Transport Layer Security) to establish a trust with each external SIP gateway or trusted domain. TLS will provide endpoint authentication by using Mutual or Two-Way Authentication on a hop-by-hop basis. With Mutual or Two-Way authentication both the server and its client will use certificates from a Certificate Authority to authenticate each other. The 2020 IMG uses a digital certificate for authentication and a public key for encryption/decryption. Once the sender is verified then the receiver will send its certificate to the sender for verification. When all information is verified then the SIP signaling can begin. Below is diagram showing the TLS certification process supported on the 2020 IMG.

The diagram below demonstrates the authentication process. Both endpoints have a common CA for their certificates. The certificate can be either a self signed certificate and key or a certificate obtained from a CA (Certificate Authority).


The 2020 IMG can act as both a Client and a Server. In the diagram above and example below, the 2020 IMG is the client and the SIP Proxy/Gateway is the server.

Example TLS exchange

An outbound SIP request is sent from the client and the transport indicates the use of TLS. A TLS connection is opened towards the server on a specific IP address and port.

  1. Client Hello - The client sends a Client Hello message specifying the TLS version and a list of suggested cipher suites it supports.

  2. Server Hello - The server responds with a Server Hello message with the TLS version and a chosen cipher suite.

  3. Certificate from Server - The server presents an X.509 certificate or certificate chain to the client for verification as part of the initial TLS handshake.

  4. Server Certificate Request - The server then requests a certificate from the client so the connection can be mutually authenticated. (optional)

  5. Server Key Exchange - The server sends the client a Server Key Exchange message with the Public Key information sent in step 3.

  6. Server Hello Done - The server sends a Server Hello Done message to tell client it is finished with initial negotiations.

  7. Certificate from client - If the server requests a certificate, the client must send the certificate or certificate chain.

  8. Client Key Exchange - The client sends a Client Key Exchange message which may contain a PreMasterSecret, Public Key, or nothing depending on the cipher suite chosen.

  9. Certificate Verify - This message is sent when the client presents a certificate as above. Its purpose is to allow the server to complete the process of authenticating the client.

  10. Change cipher spec - The client sends a message telling the server to change to encrypted mode.

  11. Finished - The server tells the client that it is ready for secure data communication to begin. This is the end of the SSL handshake.

  12. Change Cipher Spec. - The server sends a message telling the client to change to encrypted mode.

  13. Finished - The server tells the client that it is ready for secure data communication to begin. This is the end of the SSL handshake.

  14. Encrypted data - The client and the server communicate using the symmetric encryption algorithm and the cryptographic hash function negotiated in Messages 1 and 2, and using the secret key that the client sent to the server in Message 8.

  15. Close Messages - At the end of the connection, each side will send a close_notify message to inform the peer that the connection is closed.

Call Flow

Below is the authentication process shown in a call flow diagram to help understand the process.



Public Key Certificates

A Public Key Certificate provides a safe way for an entity (Client) to pass on its public key to another entity (Server) to be used in asymmetric cryptography. Asymmetric cryptography will verify that the client is who he says he is. There are two types of Certificates, CA signed and self signed. The 2020 IMG supports them both. The 2020 IMG supports the PEM (Privacy Enhanced Mail) standard for these certificates. The CA Organization will supply three PEM files which are loaded into the directory from which the 2020 IMG system software is loaded from. For example, if loading software from FTP server, the three files displayed below must be loaded in the directory that the bdn2020_ver21023_id0201.bin file is loaded from. Examples of certificate files are shown below.

Note: The user can change the names of the files below if desired.

Additional Information on the certificates

CA signed Certificate - A CA certificate is a certificate created by a trusted CA Organization that issues these certificates. The CA Organization creates the certificates which contains a public key and the identity of the owner. It is up to the CA Organization to verify the applicants credentials. The certificate is then delivered to an endpoint which is pre-configured to trust certificates that are created/assigned at a CA Organization.

Self Signed Certificate - A self signed certificate is created by the user. The self signed certificate is faster to create but is not signed by a trusted CA Organization. The self signed certificate requires that any client that connects over an SSL connection to the server that has this certificate installed, be configured to trust the signer of this certificate. Because the certificate has been self-signed, the signature is not likely to be in the clients trust file and must be added. Self signed certificates are useful when each client interacting with the server can be configured to trust the certificate.

Cipher Suites

A cipher suite is a set of algorithms that TLS uses to encrypt the data to secure a connection. When a certificate is sent from the 2020 IMG during negotiation, the two cipher suites are offered. The server will decide which cipher suite will be used. The 2020 IMG supports the following cipher suites and they are not configurable:


TLS only allows SIP entities to authenticate servers to which they are adjacent to. Establishing a TLS connection authenticates  both transport endpoints but does not authenticate the SIP messages flowing through the link. For example, two proxies may carry traffic between them over TLS but this does not stop a malicious gateway from injecting suspect SIP traffic in either end of the TLS link. SIPS can be used to ensure that TLS is maintained for all hops carrying SIP messages, therefore reducing the risk of such an attack. SIPS is enabled/disabled in the SIP Signaling Gateway Profile (SGP).


Additional Information