Troubleshooting Encrypted SIP Signaling using Teraquant TQdecrypt

 In Troubleshooting and Performance Monitoring
Reading Time: 6 minutes

As encrypted voice becomes more prevalent using TLS connections, complexities are increasing, implementation deficiencies are appearing and are having an impact on your services. The processor intensive functions of the encryption and decryption processes are showing up bottlenecks in your systems. The vast array of configuration options presents a challenge to ensure uniformity and interoperability between you and your customers and your various vendors.

It becomes essential to be able to troubleshoot and monitor the performance of the TLS layer and the services it carries.

How do you ensure your SBC’s, IP endpoints & UC infrastructure are configured correctly to allow monitoring and troubleshooting

Ensuring correct configuration of RSA key exchange to ensure Maintainability

This paper forms a series which will guide you through the implementation of encrypted services from a troubleshooting and performance management perspective . We Help put you in control of this complex field allowing you to maintain your quality levels for the communication services you provide to your customers, at the same time providing new privacy from encryption

In order to analyze protocol data messages, for example SIP signaling and media, we obviously need to decrypt the messages first. This paper illustrates what network device configurations are necessary in order to ensure all messages can be decrypted for analysis. If we monitor the session key exchange and we have the private key of the server end, then we can decrypt messages in both directions within the session and troubleshoot the IP data interaction, for example SIP signaling.

Imagine you are the service provider, and your enterprise customer is asking you to encrypt the SIP traffic used to send calls between you. You need to be able to troubleshoot these links. You administrate your SBC and will own and secure your own private keys. But you do not administrate your customers’ E-SBC and will not have their private keys. How do you ensure you can decrypt and troubleshoot all messages arriving and transmitted by your SBC and still maintain mutual authentication?

How do you troubleshoot the connection from your premises to Microsoft TEAMS cloud?

Microsoft Teams mandates encryption. Once it goes in the Teams cloud, things become rather misty. You need to be able to clear the fog and isolate the problem.

How can you ensure you can troubleshoot encrypted SIP from your end of the link, the end that you administrate?

It is all determined by which end of the TLS link is the client and which end is the server.

We need to decrypt packets in both directions to troubleshoot. Computation of asymmetric encryption keys is very CPU intensive. So the more efficient symmetric encryption algorithms is used for the high-volume user data packets. Symmetric encryption means the same session key is used to encrypt as to decrypt the application data. For most common implementations of TLS cipher-suites, the session key relates to and lasts for as long as the TCP session. Many SIP calls can be setup using the same TCP session. In some networks, this TCP session may stay up until the IP phone is rebooted or the SBC is restarted or in protocol terms the TCP session is torn down with a FIN/ACK. Within that TCP session, SIP messages are exchanged for example, a SIP call may start with a SIP INVITE, the other end responding with a 100/TRYING. The holder of the Session key can decrypt them in both directions.

To capture clear packets to troubleshoot, we need the TLS Server private key combined with whatever we capture from the key exchange happening on the wire [i.e., pre-master secret etc.]

You may notice when analyzing TLS sessions in Wireshark, some packets show with a TCP/IP header but the payload gives only the label “ Applications Data”. This is because this packet cannot be decrypted in Wireshark, because it does not have the required session key.

How do we ensure our private key that we administrate is sufficient to decrypt all sessions?

The session key is derived from the Pre-master secret. The Client Side generates the Pre-master secret from a random number generated from the Client side. The Client encrypts that random number using the server’s public key. Remember, during the RSA key exchange, the server says “Here’s my public key. Use it to encrypt the Pre-master secret that you sent to me”. The server decrypts this random number, using its private key and so both sides now know the Pre-master secret. After that it’s just some straightforward, but not so simple mathematic arithmetic computing process to calculate the session Key. The details are shown in the diagram below.

The master secret is in turn combined with the 32-byte random strings from the Hello messages using the pseudo-random function to produce the keyblock. The size and structure of the key block depend on the cipher suite used. In our example, we are encrypting with AES 256 in CBC mode and using the SHA-1 hash function for message authentication. The key block in this case consists of four keys: A 20-byte key used by the client to compute SHA-1-based HMAC authentication tags, followed by a 20-byte key used by the server for the same purpose, then a 32-byte (256-bit) AES key used by the client for encrypting data (and the server for decrypting), followed by another 32-bit AES key used by the server for encrypting and the client for decrypting. (Note that in contrast to the setup we described at the start of the course, each party uses one symmetric key for encrypting and another for decrypting.) The code for computing the keyblock is shown in Figure above. In our example, it is the third component of the keyblock that is used to encrypt data from the client to the server.

Below is given an example trace of a TLS key exchange starting with the Client Hello. This Client Hello contains protocol parameters specified by the protocol specification in the RFC. It does not explicitly contain a request for the Server’s certificate, but this is implied by the RFC.

Below is given a summary of an RSA type key exchange.

  1. Client Hello including Certificate request from Server
  2. Server Hello including optional Certificate request from Client, [Which is made in this case]
  3. Followed by “done” – the server has all it needs
  4. The client provides its Certificate to the Server,
  5. says ‘activate the new session key’
  6. verifies that Server Certificate is good
  7. and then Finishes

Establishing a Secure Session Using the TLS Protocol

The TLS Handshake Protocol follows these steps:

  1. The client sends a “Client hello” message to the server, along with the client’s random value and supported cipher suites. This message implies a request of the server to send its certificate.
  2. The server responds by sending a “Server hello” message to the client, along with the server’s random value and its certificate to the client for authentication. The server may request a certificate from the client. From this server certificate is also derived the server’s Public Key. The server sends the “Server hello done” message.
  3. If the server has requested a certificate from the client, the client sends it.
  4. The client creates a random Pre-Master Secret and encrypts it using the public key from the server’s certificate, sending the encrypted Pre-Master Secret to the server.
  5. The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on this Pre-Master Secret.
  6. The client sends “Change cipher spec” notification to server to indicate that the client will start using these new session keys for hashing and encrypting the user messages.
  7. Server receives “Change cipher spec” and the “Client finished” message from client and switches its record layer security state to symmetric encryption using the session keys. Server sends “Server finished” message to the client.
  8. Client and server can now exchange application data over the secured channel using symmetric session key. All messages sent from client to server and from server to client are encrypted using session key.

The TLS server in this case, the CSP SBC follows up the Client Hello request providing its certificate. In this case, it also requests the client’s certificate. Although this is optional, it achieves mutual authentication in the same TCP session. It also specifies that as soon as the client responds with its certificate, the TLS Cipher negotiation and key exchange is complete.

After the client and server have exchanged and verified the certificates of the other end, each side sends “Change Cipher Specs” to indicate that they would now be using the session keys to encrypt the data.

In a nutshell, the clever bit contributed by the RSA key exchange means that as long as we have the private key of the server, and are monitoring the key exchange itself, we can derive the session key and decrypt the messages in both directions to troubleshoot the messages in the clear. We do not need the private key of the client or your customer end.