IMG 1010 - SIP Signaling Over TLS Overview

Owned by Kelli Higdon
Last updated: Mar 04, 2024
5 min read

Overview:

The IMG now 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 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 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 IMG can act as both a Client and a Server. In the example below:

  • IMG = client

  • SIP Proxy/Gateway = server

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 requested a certificate the client sends 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.

Detailed Information:

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 IMG supports them both. The IMG supports the PEM (Privacy Enhanced Mail) standard for these certificates. The CA Organization will supply three PEM files which are then loaded into /home/excelsw/ftpBuilds folder. Examples of files are shown below.

  • privateKey.pem

  • publickey.pem

  • CAList.pem
     

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


Below is information on each of 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 and 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 installs this certificates 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 IMG during negotiation, the two cipher suites are offered. The server will decide which cipher suite will be used. The IMG supports the following cipher suites:

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_RSA_WITH_RC4_128_MD5

The cipher suites are not configurable.

SIPS:

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 IMG 1010 - SIP Profile - 10.5.3 pane.

Supported Information:

  • The IMG supports SSLv3 and TLSv1.

  • TLS is supported only over TCP and requires a separate port. The default port is 5061 and is configurable in the SIP Signaling object.

  • The IMG supports 128 Bit Encryption

  • A Certificate Database is created and uploaded to the IMG.

  • The IMG will allow a maximum of 16 Trust ID's or Certificate Entries

  • TLS is also supported on the IMG's virtual IP addresses

  • The IMG supports X.509 certificates only and supports a maximum depth of CA certificates during certificate verification to four.

  • The use of certificates requires that the clock on the IMG be synchronized with the network time to ensure proper validation of certificates. To configure clock see IMG 1010 - Configure SNTP on GCEMS Server

Not Supported:

  • CRL (Certificate Revocation Lists) are not supported.

  • SNMP or MIB requirements are not supported.

  • DNS or ENUM lookups of NAPTR/SVR records containing SIP URI's is not supported.

Return to Documentation Home I Return to Sangoma Support