Transport Layer Security (TLS) Explained

by Andrew Prokop | Arrow Systems Integration

Over the course of several blog articles I’ve mentioned some of the security aspects of SIP. In Proving it with SIP Authentication I discussed the use of response messages and authentication headers. That kind of security is delivered at the protocol level. In other words, SIP clients and servers exchange messages that enforce identity-level security. Of course, since SIP itself is a text-based protocol we need something that protects the messages and their content from prying eyes. Enter Transport Layer Security (TLS).

TLS is an evolution of an earlier protocol called Secure Socket Layer (SSL). SSL was developed a number of years ago by Netscape (remember Netscape?) and was used to encrypt data sent between a web browser and a web server. You knew that you were using SSL when the address line of your browser contained “https” and not “http.” Some browsers would also display a lock symbol when SSL was in use.

Like most of the other protocols used by SIP, TLS is controlled by the Internet Engineering Task Force (IETF). At first, TLS and SSL weren’t all that different from one another. However, since its original definition in 1999, TLS has continued to evolve into a highly secure transport protocol for both web and real-time protocols such as SIP.

At the core of TLS are certificates and the concepts of symmetric and asymmetric cryptography. I could write thousands of words about these three, but you can learn enough to be dangerous in just a few paragraphs.

First, a certificate is a form of digital ID that an entity uses to identify itself. Think of it as a driver’s license for IP components. However, to prevent nasty people from forging those driver’s licenses certificate authorities (CA) exist which are used to validate the authenticity of the certificate. There are private CAs that an enterprise operates. There are also public CAs which are available via the Internet. VeriSign is an example of well-known public CA.

Next comes symmetric and asymmetric cryptography. Both have to do with how data is encrypted and unencrypted. In the case of symmetric cryptography, data is encrypted with a key. It’s also unencrypted with the same key. So, if two different entities have that key they can send encrypted data back and forth and no one without that key will understand what they are saying. The strength of symmetric cryptography is that it is fast and uses a minimal amount of processing power. The weakness is that you need a secure mechanism to exchange the key.

Data is also encrypted with asymmetric cryptography, but in this case there are two keys – the public and private key. The public key is usually contained within the certificate of an IP entity and anyone with that certificate will have the public key. The private key is kept secret and is never revealed to anyone. These two keys work together to encrypt and decrypt data sent on an IP connection. Data encrypted with the public key can only be unencrypted with an associated private key. Data encrypted with the private key can only be unencrypted with the matching public key. This form of encryption is known as Public Key Cryptography. It requires more processing power than symmetric cryptography, but it creates a secure data link that only the client and server can decipher.

I wrote that TLS uses both symmetric and asymmetric cryptography. It uses symmetric for authentication and asymmetric for the encryption of the bulk data. In our case, that bulk data would be the SIP messages and responses. Note that this data does not include the actual media flow such as G.711 or G.729. That data is encrypted using Secure Real-Time Protocol (SRTP) — a blog for another day.

If you are still reading I applaud your tenacity. This is not easy stuff to understand. Keep in mind the following, though, and you should be fine. Certificates are used to verify the authenticity of clients and servers. Certificate Authorities exist to verify that certificates are not forged. Public and private keys are used to encrypt the messages that are exchanged between SIP entities. This means that with TLS you can safely use the unsecure Internet to establish secure SIP conversations. Even if your SIP messages are intercepted, they won’t do anyone any good since they will not be able to understand what is being said.

Just so you don’t think this isn’t all academic babble, here at Arrow SI we enforce TLS encryption on all our remote SIP endpoints. Our Avaya SBC will not allow SIP devices and soft clients (9641, Flare, One-X Mobile for IOS, etc.) into our network if TLS is not turned on. We take security seriously and so should you.

Share this article

The thoughts and opinions in these blogs belong to the individual blogger and do not necessarily represent the views or opinions of Arrow Systems Integration.