SSL Decode Failure Overview.
Article ID: 30776
Updated On:
Products
Issue/Introduction
Question:
Why is TIM seeing a high number of SSL decode failures?
Answer:
The common cause could be an incorrect private key, unimplemented ciphersuites, or an unknown SSL session (SSL across different TCP connections and Tim aged out SSL sessions). Unfortunately, Tim/CEM does not report SSL failure with an associated cause or provide a SSL troubleshooting tool.
Due to the nature of the SSL Protocol, if changing or uploading a new SSL Certificate, or restarting the TIM (which is the same from the SSL point of view), all already valid SSL Sessions can not be decrypted ! This means for existing SSL traffic on production systems, there are a large decode failures in the beginning, but this will stabilize through time. So, before taking any action, wait 15 minutes to see if the decode failures are still growing as fast as before.
When installing a SSL-Key onto the TIM for sniffing encrypted Traffic, many SSL-Connections may already be active. However, the TIM needs to see the IKE (Initial key Exchange) between the Client Browser and the Web-Server to be able to decrypt the Traffic. If TIM does not see the IKE, then no SSL Decryption will occur.
Try the following suggestions to help troubleshoot the problem:
=============================================
1. Verify that CEM has installed the latest SSL private key and check if the private key itself requires a pass phrase and make sure the right one is used when upgraded to CEM.
2. Restart the TIM (to reset the total connection counter) then monitor decode failure in "View SSL servers" page. If the decode failure count is about the same as total connections after restarting Tim then it is probably the wrong private key.
3. Tim uses the ssldump code base for ciphersuite so we can run ssldump to decode and compare it to Tim's decode failure rate.
Install ssldump on the CEM box (Tim machine) and run this command again:
#ssldump -i eth1 -Ad -k -d decrypt and display the application data traffic.
This shows if ssldump can decrypt all traffic on the Tim machine. Then try to see if a SSL session is established before TIM is started.
Some more causes of Decode errors:-
*********************************************************
4. TIM ages out an SSL session. This is configurable in TIM settings (SslSessionAgeOutSeconds), and the default is 300 seconds (5 minutes). Consider increasing this number in case a session is idle for more than 5 minutes.
5. The SSL session was established before TIM starts running. This explains why there are always bunch of SSL connection failures when TIM restarts. Also SSL sessions can be used across different TCP connections.
6. SSL decoding is strictly an agreement between a server and a browser. It is possible that the encryption uses an algorithm that TIM doesn’t know how to decrypt.
7. A client that connects and then disconnects without ever sending any data.
Environment
Component:
Feedback
