Passive SSL/TLS Interception

In passive SSL/TLS Interception the interface between the Application and the SSL/TLS library is modified to make a copy of the clear text. The clear text and TCP/IP session information are then sent (through a software agent) to the MetaFlows sensor for analysis.

Our unique patent-pending technology makes SSL/TLS interception completely passive and therefore:

  • Does not require in-line devices.
  • Does not require management of additional cryptographic keys (which can lead to security risks).
  • Does not impact network availability (see for example this).
  • Does not compromise the end-to-end SSL/TLS sessions between client and server.
  • Eliminates additional security threats.

We currently support passive SSL/TLS interception on a recent Linux distribution, Windows 10 and Windows Server 2016. We currently do not yet support Windows applications based on 64-bit schannel (like Microsoft Edege).

Passive SSL/TLS interception is today available as an appliance capable of sending decypted traffic to any existing network monitoring system (such as the MSS sensor) as if it was generated by a mirror port.

A diagram passive SSL/TLS Interception

Why Passive SSL/TLS Interception

SSL/TLS interception is usually achieved by routing or proxying the encrypted sessions through a 3rd party security device which terminates the SSL/TLS session, decrypts the content and re-encrypts it before communicating with the intended recipient. Some issues associated with such in line architecture are:

  • Cost.
  • Increase in Latency.
  • Decreased network availability due to failures or misconfiguration of the inline device.
  • Additional key management for the inline device (offers additional security risks).
  • Implicitly handles the end-to-end trust relationships between client and servers thus giving users less visibility.
Passive SSL/TLS Interception is more cost effective and more secure

The cost of passive SSL/TLS interception is lower than traditional techniques because it does not require an inline device to continuously perform cryptographic operations in real time to first decrypt and then encrypt all traffic to inspect. An inline device required to perform these operation must have considerable CPU power and must provide redundancy to prevent network outages due to hardware or software failures.

Because the SSL/TLS interception is passive, any failure of our system does not impact the normal availability of the SSL/TLS connections which can go on unimpeded. The worst that can happen in a passive SSL/TLS interception system is its inability to intercept clear text. Because we leave the original SSL/TLS end-to-end negotiation intact but just observe it, we do not introduce any additional potential security threats or force invisible and implicit trust relationships between the client and the server.