Decryption Is Key for Enhanced Security and Monitoring
Part 3 of a series on Transport Layer Security and nDA
In Part 1 of my series on Transport Layer Security (TLS) decryption, I went over a few basics of encryption, discussed TLS 1.2, and concluded with the improvements that TLS 1.3 provided. In Part 2, I discussed TLS decryption in TLS versions 1.2 and 1.3. In this final installment of the series, I discuss why TLS is still secure despite the capabilities of NETSCOUT’s nGenius Decryption Appliance (nDA) and outline ways to ensure that you handle decrypted traffic appropriately.
Why TLS Is Still Secure
So, after seeing how TLS can be decrypted, you may wonder if you should be concerned that your TLS sessions are being decrypted or if any TLS session can be decrypted. Here are some points to remember and tips to determine if your traffic can be (or is being) decrypted.
- The client and server can always decrypt the session. This must be possible at both endpoints; otherwise, the endpoints would not be able to process the information between the two systems. If you are interested in doing this on your own traffic, it is straightforward to start capturing the session keys on your local system and loading those keys into a program that can decrypt packets. Most browsers support saving the encryption keys to a specific folder on your computer, and these can be loaded into a program to decrypt the captured network traffic.
- You can verify the connection on your HTTPS sessions by clicking the lock icon in your browser. Find the certificate that the server sent to you and look through it. NETSCOUT’s, for example, looks like the following:
A certificate that is self-signed will look like the following:
In addition, when nDA is used to decrypt traffic, the end user can still see that this is happening. Take a look at the following certificate:
As you can see, www.google.com is signed by nDA Demo. This allows the end user to see that even though the certificate is valid, it was not issued by Google.
- Anyone with the server private key will be able to decrypt the message. This can be useful for passive monitoring of your own servers. You can copy the private key to a system that is passively monitoring the system and decrypt TLS up to 1.2. TLS 1.3 cannot be decrypted via this method. The reason for this is the Diffie-Hellman key exchange, which ensures that only the client and server can decrypt the message.
How to Properly Handle Decrypted Traffic
So, now that you have decrypted some traffic, what are a few things to keep in mind when handling it? Handling this traffic properly is extremely important, because there was a reason it was encrypted in the first place.
The best way to handle your decrypted traffic is by sending it directly to the device that is going to analyze the traffic. This can be done with a NETSCOUT Packet Flow Switch. The benefit is that multiple copies can be sent to different appliances. Decrypt once; analyze with multiple tools.
Do not send the traffic over an IP network unencrypted.
You may run into compliance issues if you plan to store the traffic. If an appliance is going to store the traffic, it is probably best to use a tool that can obfuscate credit card and social security numbers.
nDA allows for decrypting TLS sessions in multiple ways and, when combined with a Packet Flow Switch, allows for analyzing that decrypted traffic via multiple appliances. This is a great way to securely analyze traffic on your network for both security and application performance monitoring purposes.
Learn more about NETSCOUT’s nGenius Decryption Appliance (nDA).