CA Application Performance Management Agent (APM / Wily / Introscope)INTROSCOPE
Getting the below SSL Vulnerability highlighted by internal team
Vulnerability - SSL Version 2 and 3 Protocol Detection The remote service accepts connections encrypted using SSL 2.0 and/or SSL 3.0. These versions of SSL are affected by several cryptographic flaws, including: - An insecure padding scheme with CBC ciphers. - Insecure session renegotiation and resumption schemes. An attacker can exploit these flaws to conduct man-in-the-middle attacks or to decrypt communications between the affected service and clients. Although SSL/TLS has a secure means for choosing the highest supported version of the protocol (so that these versions will be used only if the client or server support nothing better), many web browsers implement this in an unsafe way that allows an attacker to downgrade a connection (such as in POODLE). Therefore, it is recommended that these protocols be disabled entirely. NIST has determined that SSL 3.0 is no longer acceptable for secure communications. As of the date of enforcement found in PCI DSS v3.1, any version of SSL will not meet the PCI SSC's definition of 'strong cryptography'.
Vulnerability - SSL Medium Strength Cipher Suites Supported The server's X.509 certificate cannot be trusted. This situation can occur in three different ways, in which the chain of trust can be broken, as stated below : - First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority.
- Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's 'notBefore' dates, or after one of the certificate's 'notAfter' dates.
- Third, the certificate chain may contain a signature that either didn't match the certificate's information or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize. If the remote host is a public host in production, any break in the chain makes it more difficult for users to verify the authenticity and identity of the web server. This could make it easier to carry out man-in-the-middle attacks against the remote host.
Basically these vulnerbilites are not affected because TIM is desinged to work inside the DMZ zone. So no once has access to the TIM out side.
But the vulnerbitlites can be mititgated by removing SSL2 and SSL 3 from the ssl.conf file from the TIM installation.
To remove sslv2 and 3, you need to go to the /etc/httpd/conf/ssl.conf file and remove the sslv2 and sslv3 from there. Or if you have httpd installed in some where in the TIM machine you can go to that location find the ssl.conf file and then delete the SSLV2 and V3 leaving only TLS only for communication.