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
Manish
Hi Manish:
There are a variety of Knowledge Documents on this topic. The best one that answers your question is
Dear Manish:
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
Hal
Thanks for the quick response. Let me review them and see if that resolves my issue. I will provide feedback early tomorrow.
Hi Manish,
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"
Regards,
Lynn
Hi Manish:
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?
Thanks
Hal German
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.
Cheers,
Manish
Hi Manish:
Your questions and feedback are always welcomed. I will mark this thread as answered since activity is being pursued through the case
Thanks
Hal 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)?
Thanks.
Manish
Hi Manish:
>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.
Thanks
Hal German
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"?
etc...
Hi Manish,
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
Regards,
Lynn
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>
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 also updated the supported ciphers KB to reference Joerg's JMertin public GitHub page
on May 24, 2016
Dear Manish:
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
Hal