When I login to TIM Setup Page Under CEM (Web UI) and go to "View TIM SSL Server Status", I get the following info
So, I am not sure what to do here for "Unsupported cipher suites" column. It's my first experience with this type of issue. Do I need to make changes to anything w/n TIM to fix this issue?
My TIM is not MTP enabled. I am using APM/TIM v10.1
Thanks in advance
There are a variety of Knowledge Documents on this topic. The best one that answers your question is
And this one Seeing SSL Decode failures with correct private keys and supported SSL cipher suites.
That should answer your questions. Please let me know if that is sufficient and we can mark the thread as closed. Or if there are followup questions
Thanks for the quick response. Let me review them and see if that resolves my issue. I will provide feedback early tomorrow.
Further to Hal's response if you enable "Trace SSL Errors" under "Configure TIM Trace Options" and in "Configure TIM Settings" increase the log file size property MaxLogSizeInMB from default 1MB to 50MB you should be able to capture the actual cipher suite names in the timlog.txt files.
These KBs may also be useful:
"There is additional support for TLS 1.1/1.2 in APM TIM 10.x and 9.6/9.7 Hot Fixes, but what are their supported ciphersuites"
"The TIM log is showing "TLS 1.2 CipherSuite - Unknown (49200)" but how do I find the name of the unsupported ciphersuite to disable in my web server"
The TIM log is showing "TLS 1.2 CipherSuite - Unknown (49200)" but how do I find the name of the unsupported ciphersuit…
The KBs provided should give you a good start on this issue. Are there any additional questions or may we mark this thread as closed?
Hallett_German / Lynn_Williams
I've opened up a case with CA Support since we will need to focus on the "Connection with decode failures-Total" and not the other one. We will have to gather a pcap and analyze it thoroughly. Once we have done that and come up with a successful resolution..........I will provide a feedback to this thread.
Thanks again for all your help.
Your questions and feedback are always welcomed. I will mark this thread as answered since activity is being pursued through the case
Ok, thanks Hallett_German
Are there any TIM 10.1 hotfixes/patches I can apply to address the "decode failures" of more than 50% I am getting? From what I've read so far on Community about this matter, looks like if
TIM receives an empty package to decode then it will fail
TIM doesn't receive an entire package together then it will fail
TIM receives a mis-aligned package to decode the it will fail.
So, is there a way for TIM to have the smarts to circumvent these simple road bumps (in a form of applying hotfix/patch)?
>So, is there a way for TIM to have the smarts to circumvent these simple road bumps (in a form of applying >hotfix/patch)?
From time to time, the TIM adds minor "fixes" to deal with network data that is not protocol compliant or having integrity issues. None of these will "resolve" the use cases that you discuss. In theory all of the cleanup/filtering should take place before the TIM receives the data.
I suggest that you create an enhancement if wishing to pursue.
Actually my use cases are aligned, I would think. So, that is why I ask.
We have empty packets that TIM is trying to decode (which will fail)
We have out of aligned packets that TIM is trying to decode (which will fail)
We have broken traffic that TIM is trying to decode (which will fail)
If the traffic TIM gets is not the same as the real traffic, it will monitor something else than the real traffic
Are there hotfixes/patches that can be installed where TIM can ignore
empty packets and not consider it as "decode failure"?
un-aligned/broken packets it tries to decode and no consider that as a "decode failure"?
The short answer is there are no fixes for what you describe.
The TIM processes all packets that it receives after it has been through any defined Web Server Filters or MTP Hardware Filters.
So per Hallett_German's comments, the traffic needs to be as clean as possible by the time it reaches the TIM and the fact that TIM highlights poor quality traffic is probably a good thing as that could be seriously impacting accurate CEM monitoring.
Hope that helps
Thing is - we could use the HotrFixes blind - but that will not mean that these will fix issues.
So far there are hotfix's that address specific issues - like micro-misalignment in the 3way handshake phase, or not crashing on SSL packets with empty payload etc. So in that regard Hal and Lynn are right.
The unsupported cipher tag usually tells us that the used cipher is not compatible with the one in the TIM. So TIM has already identified the traffic type (TLS v1.0/1.2/1.3) etc., but the cipher combination is not correct.
Decode failures usually come from a missing IKE set.
I'm afraid this will require us to actually check the traffic again that is onsite - and will require us to do a health-check of the installation again.
Any chance you could provide us some data using the apm-scripts -> On public github now>
GitHub - CA-APM/fieldpack.apm-scripts: Provides scripts to collect data for troubleshooting an APM 9.x or later installa…
Please get a SYS/TIM and PCAP. A TIMPERF would also be welcome.
Before we can provide you the right HotFix, we need to know which one would actually address the issues you are seeing. But for that we need to know what the issue is.
I will look at that github link
I also updated the supported ciphers KB to reference Joerg's JMertin public GitHub page