Securing SIP and VoIP Calls with TLS and SRTP

When you make a call, it's the SIP protocol that contacts the receiving device, agrees on the nature of the call, and makes the connection. After that, another protocol carries the content RTP (Real-Time Protocol) of the call. When the call is over and the parties disconnect, SIP is again the protocol that terminates the call.

This may not sound like much of a security issue, but in fact, it is. That's because SIP wasn't originally designed to be secure, which means it's easily hacked. SIP is a text-based protocol. The same applies to RTP, another text based protocol for handling your calls audio/video/media. Unless an encrypted connection is requested, all of this takes place as plain text, that may travel across the open internet or your office network.

At Telnyx, we provide users with the ability to establish TLS (Transport Layer Security) and SRTP (Secure Real-Time Transport Protocol) with our system for end-to-end SIP and Media encryption. By default, the features are not enabled, but are configurable from your SIP Connection. Additionally, at Telnyx, we leverage our private network to pull your traffic off the public internet and carry the media across our own fiber. By handling the media, we are able to ensure that your packets are exposed to as few public hops as possible.

In this article, we'll talk a little about how certificates work, how TLS sessions are established, and provide a brief overview of SRTP with example SDP paylods.

Certificates are used for authentication and encryption. They're always used with TLS. There's an SSL (TLS) certificate for sip.telnyx.com:5061 so that SIP-over-TLS traffic between our customers and Telnyx can be secure.

TLS/SSL certificates used for SIP are exactly the same as those used for HTTPS. There's no difference because TLS makes a separate transport layer and the protocol inside the TLS is independent of TLS. When a browser attempts to connect to a secure website using TLS, the web server sends a certificate (and proof that the server is properly using that certificate). The use of certificates is based on chains of trust.

The browser has a list of certificates that it trusts, but it does not have a list of all certificates. If the browser is to trust the certificate from the server, then the certificate is signed by a CA. Every certificate has an issuer (the certificate that signed it), and the chain of trust ends (or starts, depending on perspective) with a Root CA certificate. If the certificate from the web server is signed by a CA Certificate that the browser trusts, then the browser will also trust the server certificate. (Root CA certificates are signed by themselves, so are only ever explicitly trusted.)

Whenever a client connects to TCP:sip.telnyx.com:5061, the server sends a certificate chain: a bundle of the server certificate and the two intermediate certificates. If the client trusts the Root CA certificate that issued the topmost intermediate certificate, then (by the chain of trust) it'll implicitly trust the sip.telnyx.com server certificate.

Modern operating systems (Android, Ubuntu, MacOS, etc) have certificate bundles built in. The user usually does not have to configure certificates. When new Root Certificate Authority (CA) certificates are made or certificates are revoked, OS updates look after keeping the CA bundle updated.

Some customers use appliances for SIP traffic. An example is an SBC (Session Border Controller), such as Audiocodes M1000, Dialogic Bordernet SBC. These appliances route SIP traffic but they don't run an Operating System (OS) and don't have a comprehensive CA bundle built in.

If these devices are to trust the certificate from sip.telnyx.com, then they must either trust the certificate directly or trust (either of) the intermediate certificates. To do this, the administrator must load a certificate into the appliance; this is usually a manual task.

Without loading a certificate to establish the trust, TLS connections cannot be made to sip.telnyx.com:5061 and therefore SIP over TLS cannot work. You can often determine this by checking the network traffic, where the client will return "Unknown CA" in the alert response when Telnyx shares the Certificate and Server Key Exchange.

You can also check the certificates, fingerprints, and expiry dates for sip.telnyx.com:5061 using the below example openssl commands on the command line / terminal / prompt.
​
​Note: We also allow customers to use both publicly and privately signed certificates.

Certificates

​Fingerprints

​Expiry Date

SSL and the newer version TLS are cryptographic protocols that provide security on the Internet. TLS with SIP is used to encrypt sip signaling whereas SRTP (Secure Real-time Transport Protocol) is used to encrypt media streams. It is not mandatory to use SRTP when using TLS but in order to use SRTP effectively, one must use TLS.

TLS/SSL Handshake Protocol

The TLS handshake protocol is used between sip client and server to establish trust and then negotiate what secret key will be used to encrypt and decrypt the traffic.

TLS runs atop the TCP protocol, so the first thing that is performed is TCP three-way handshake. Once the TCP connection is established, SSL/TLS handshake can take place.

Step 1: Client initiates "Client Hello" which has information such as TLS version, cryptographic algorithm and data compression method supported by the client.

Step 2-6: Server sends "Server Hello", agreeing on the cryptographic algorithm from the list provided by the client, amongst other parameters . It then presents its digital certificate and public key.

Step 7-13: Client validates the certificate presented by the server. Once the client trusts the server, key exchange (shared secret key) will take place.

Step 14-15: Encrypted data will flow between the two endpoints and can continue until either party chooses to close the connection.

When using Diffie-Hellman key exchange, Telnyx only supports keys sizes of 2048 bits or larger. Please make sure the key size offered by your client can meet this minimum in order to ensure encrypted data can flow between our servers and your client

The greater technical community has identified TLS 1.0 and TLS 1.1 to no longer meet modern standards for encryption and privacy. We aim to provide these protections to all of our customers.

In light of this, Telnyx will no longer support TLS 1.0 and TLS 1.1 after June 1st, 2021.

Before June 1st, 2021 you may need to take action to ensure that your applications continue to work without interruption. For more information on this change and how it may affect your applications, head to our Developer Center.

Once the TLS session is established, the SIP session will now take place where the negotiation of media will also be handled. Note that, with SRTP, the encryption parameters for the RTP are contained within the SIP signaling (which is why TLS should be used for SIP in the first place).

Actually, the parameters for the encryption are in the SDP (the Session Description Protocol), which is a part of the SIP message.

Remember, credential-based SIP Connections must register over TLS if you want inbound calls to be established over TLS. For FQDN and IP authentication based SIP Connections, you can specify the transport of choice in the SIP Connection settings.

The Secure Real-Time Transport Protocol. SRTP is a security profile for RTP that adds confidentiality, message authentication, and replay protection to that protocol. It was initially published by the Internet Engineering Task Force (IETF) in RFC 3711 in March 2004.

SRTP uses Advanced Encryption Standard (AES) as the default cipher along with two different cipher modes. Segmented Integer Counter Mode is standard, and is critical for running traffic over an unreliable network with a possible loss of packets. f8-mode is used for 3G mobile networks, and is a variation of output feedback mode designed to be seek-able with an altered initialization function.

While AES-128 is widely regarded as more than adequately secure, some users may be motivated to adopt AES-192 or AES-256 due to a perceived need to pursue a highly conservative security strategy. In the below example, you'll see Counter Mode (CM) and Galois Counter Mode (GCM).

Besides the AES cipher, SRTP allows the ability to disable encryption outright, using the so-called NULL cipher, which can be assumed as an alternate supported cipher. In fact, the NULL cipher does not perform any encryption if chosen. You'll also notice some suites containing the Hash-based Message Authentication Code with Secure Hashing Algorithm 1 (HMAC-SHA1) used for integrity checks between sender and receiver on the authentication tag. If the message authentication fails and the results don't match, the packet is discarded.

In this case the cipher suite 5 is chosen.

For security reasons, you may encrypt your SIP signalling over TLS to protect the content of the SIP messages. For encrypting media, you need to use SRTP.

Credential-based SIP Connections must ensure the client specifies TLS when attempting to REGISTER with our system, in order for inbound calls to be established over TLS.

Conversely, to use TLS for outbound calls, the customer should configure his client's (server or phone, etc) transport type and choose TLS for the SIP signaling.

For IP and FQDN SIP Connections, please make sure you review your inbound settings and specify the transport as TLS. This will ensure Telnyx sets up any inbound calls over TLS.

The media settings for SRTP are also configured in the Connection, under both the Inbound and Outbound tabs.

When Telnyx receives a call destined to a number associated with your SIP Connection, and this SIP Connection has SRTP enabled, we will send the cipher suites in our SIP INVITEs SDP. Please make sure your system is configured to respond with a preferred cipher suite in it's 183/200 OK.

Once you enable either protocol, please ensure your system is also set up to negotiate with either protocol. Otherwise, you may see Telnyx may send back a 488 Not acceptable SIP response or a SIP 503 with a cause code of 88 and the reason as incompatible destination.

For instance, if you enable SRTP for your outbound calls but do not send us the cipher suites in your SIP INVITEs SDP, we can't establish an encrypted media channel and this will result in a 488 Not acceptable response with a cause code of 88 and the reason as incompatible destination.

However, you can configure device to use SRTP and make calls without further configuration from the Telnyx Mission Control Portal. In other words, you can send a SIP INVITE with cipher suites in the SDP without having to explicitly enable SRTP on the SIP Connection - Telnyx will continue honour the offer and ensure the media is encrypted.

If you are using a WebRTC client to make calls, you do not need to enable encrypted media settings on the SIP Connection. WebRTC clients inherently connect over encrypted WebSockets to rtc.telnyx.com, ensuring secure signaling and media transmission without additional configuration. If you enable these settings, you may encounter an error during call establishment. Clearer warnings will be presented on the SIP Connection settings in the near future.