Limited TIM SSL Support and Available Workarounds

Document ID : KB000111921
Last Modified Date : 22/08/2018
Show Technical Document Details
Introduction:
In today’s modern web environments, HTTPS and SSL are key to ensuring the security and privacy of transactions and business services.  
 
In the past few years there have been many public and embarrassing security breaches which have forced the industry to increase different aspects of SSL and HTTPS.
 
One of these changes is the more prevalent use of Diffie Hellman (DH) key exchange. 
 
DH is designed to eliminate the possibility of the “man in the middle” decryption scheme by ensuring only SSL end-points can securely exchange ciphers.  Unfortunate this “man in the middle” decryption is the basis for all passive web monitors who are in-between these SSL endpoints like APM’s CEM Transaction Impact Monitor (TIM). 
 
Another is the use of “Extended Master Secret” for TLS which also works to eliminate the ability to inject arbitrary data into the beginning of a secured connection.  This also affects passive web monitoring in a similar way to DH.

These recent TLS features are not supported by APM TIM.
Question:
What are some the limitations with APM TIM and available workaround?
Environment:
All supported APM TIM releases
Answer:
To maintain the capability of the TIM to view and understand web traffic in these situations, the following techniques are recommended;
 
  • Create an SSL end-point before the TIM which provides the TIM with unencrypted traffic
    • This can be accomplished by using many “off the shelf” load balancers which can feed un-encrypted traffic to the TIM before re-encrypting the payload.
    • Deploy a hardware SSL Decryption device before the TIM as the SSL endpoint.  Examples of products which can meet this requirement are “Symantec SSL Visibility Appliance” and “Gigamon GigaSecure”.  CA advises customers to work with the chosen hardware vendor to validate the solution for their specific environment and deployment architecture.
    • Deploy a proxy or webserver to act as an SSL end-point.  CA has tested the open source “HA-Proxy” as part of field implementation testing, but advises customers to choose a proxy that they are familiar with and have support arrangements as CA does not directly provide support for any specific 3rd party proxy solution.
 
  • Use CA Browser Agent instead of CEM to collect web performance and quality information
    • Note: This requires that the application has a JavaScript engine on the client side and measures at the individual client end-point and not a consistent point in the data center.
 
 
Additional Information:
https://comm.support.ca.com/kb/tim-shows-ssl-decode-failures-for-tls-1x-packets-which-use-extension-extended-master-secret-tim-log-contains-message-block-size-greater-than-plaintext/kb000005473

https://comm.support.ca.com/kb/which-cipher-suites-are-supported-cemtim-for-decoding-ssl-hosted-applications-and-how-can-i-check-those-against-the-ciphers-installed-on-my-web-servers/kb000031391