Understanding Transport Layer Security (TLS)

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.


  1. Hi Andrew – thought/question: How often do you see encryption used for VoIP connectivity? In my world I still don’t see that much of it. Even though I think we should be seeing more – especially on Public Internet facing SIP interconnects to ITSPs from SME/SOHO customers.

    Some providers “get around” the issue by only providing SIP trunking over VPN services. I guess it could be related to historic lack of support in products?

    Oh – and based on your Nortel heritage – what ever happened to UniStim? (He He).


    1. Neill, you won’t see any TLS from a SIP carrier. They all feel that they provide a sufficient level of security by the use of an MPLS network. Level 3 played with it for a short while, but it was only for federal customers and they quickly dropped it. I see TLS all the time in the enterprise space — whether it’s within the bounds of their network, or across the Internet to remote SIP devices. It would be foolish to send clear-text SIP across an unsecure network.

      I am not a big fan of VPN for SIP connections. With VPN you open up your network to everything on the device. I would much rather see TLS/SRTP come through a Session Border Controller. This will permit the SIP traffic to come in and out without compromising security.

      UniStim is alive and well in the CS1000 space. Some folks have moved their endpoints to SIP, but the vast majority will stay there until they replace their old Nortel equipment with something else. Until then, UniStim does the job it was designed to do. You get a ton of phone features with a low overhead protocol.

  2. Wow, UniStim – alive an’ kickin. As the quote say “The best thing about standards is there are so many to choose from!”

    1. Yep. Don’t expect Avaya to update it, but it will be there until the last CS1000 is put to rest.

  3. What about SIP register, notify and publish messages. How can these be made secure with SIP over TLS

    1. Every SIP message can be secured with TLS. TLS encrypts the SIP data stream and not just individual messages. REGISTER, NOTIFY, PUBLISH, and any other SIP message can sent via TLS.

  4. Hi Andrew,

    If I’m not worried about encryption part and my concern is limited to authentication only, does MD5 serves this purpose? OR is it possible for someone to break MDP authentication process to make unauthenticated calls?


  5. Harishankar · · Reply

    Hi Andrew,
    If TLS is used for encryption, how is the private keys transferred to the clients. I see, TLS is used in the case of Wifi calling over the public hotspots.

    1. First, you never send the private key to a client. It has to remain secret. You exchange public keys.

      This may help: https://msdn.microsoft.com/en-us/library/windows/desktop/aa380513%28v=vs.85%29.aspx

  6. Hi
    Can we do the TLS procedure with INVITE/SUBSCRIBE instead REGISTER

    1. TLS can be applied to all SIP messages.

  7. Asymmetric for authentic action and symmetric for encrypting SIP data?

  8. aakash · · Reply

    Hi Andrew,
    I have read about SIPS and also about “best-effort TLS” & “TLS-only” . RFC says a sips requests is a must all the hop secure sip communication, but at the same time it further gets confused that any intermediate proxy can not be sure if the request has come till it via only secured way (because of SIPS) . So I am puzzled if a INVITE has sips means :
    a. it reaches till the UAS domain via all secured hopes only
    b. if any intermediate proxy/hop do not imply sips will it reject the INVITE (means call fail?) or only through HOP request would go as SIP and not SIPS

    it will great help if you can help me clear my doubts!! (I spent a lot time on web getting clarification 😦 )

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: