Passive TLS mirroring

TLS inspection provides visibility of network threats hidden inside TLS encrypted sessions. This functionality is provided today by either Active or Passive TLS Interception.

Active TLS Interception is achieved by inserting a cryptographic system inline (for example a web proxy or man-in-the-middle appliance) between the clients and the servers. These inline systems can then make a copy of the clear text before/after encrypting/decrypting, inspect it locally and optionally send it out to another device (TLS mirroring).

Passive TLS Interception can be achieved by snooping the ephemeral session key of each TLS session and provide the key to the network monitoring system. The network monitoring system can then use the key to decrypt and inspect the TLS payloads.

Both of these techniques require extra hardware (whether it is virtual or not) and additional cryptographic operations. They also introduce significant complexities, some vulnerabilities and additional points of failure.

Passive TLS mirroring

Passive TLS mirroring is a hybrid between active and passive TLS interception that (1) is well suited for both public cloud and on-premise environments, (2) is much simpler to implement and (3) does not require additional hardware or cryptographic operations.

Passive TLS Mirroring leverages open source TLS implementations and works by making a copy of the clear text at the interface between the application (like httpd or curl) and the TLS library (like opnessl). Coupled with a patent-pending algorithm to map the text to network flows, this unique mechanism implements a reliable TLS mirror of the decrypted TLS sessions without sharing keys or requiring additional cryptographic operations. The open source portion of the mechanism is exemplified below:

send(security_context,clear_text, destination) {
   send_to_agent(clear_text); //added by MetaFlows
   encrypt(security_context,clear_text,encrypted_text);
   transmit(encrypted_text,destination);
}
receive(security_context,encrypted_text) {
   decrypt(encrypted_text,clear_text);
   send_to_agent(clear_text);    //added by MetaFlows
   return(clear_text);
}

As you can see, we simply provide a local agent (called sslcollector) the clear text messages by adding a simple instrumentation (send_to_agent) to the send and receive TLS API calls. The clear text is then forged into TCP/IP packets that mimic the corresponding TLS session. Optionally, we can also decode HTTP2 to appear as traditional HTTP 1.1.

Cloud-based passive TLS mirroring
Passive TLS Mirroring a public cloud like AWS

Passive TLS mirroring works especially well in cloud based deployments where the mirrored TCP/IP packets are sent (optionally encapsulated in a TLS tunnel) to an external monitoring system such as a remote IDS sensor. Each system being monitored would execute the command below:

sslcollector -I <iface> -t <ip_address> 

The IDS sensor at <ip_address> would replay the decrypted packets to <iface> by executing:

sslcollector -C -o <iface>

The IDS sensor simply receives the decrypted TCP/IP traffic without having to perform any decryption or having to fetch or manage ephemeral session keys in real time.

On-premise passive TLS mirroring
On premise Passive TLS Mirroring

Our technology also works on-premise. In its simplest form, the clear text obtained from the application is replayed through a secondary interface to an external switch. Each system being monitored would execute the command below:

sslcollector -I <iface1> -o <iface2>

The switch aggregates the mirrors and sends them to the IDS system. In a more port-efficient, on-premise implementation a simple Linux aggregation appliance can aggregate multiple mirrors before sending them to the switch.

Comparison

The table below compares important features of existing TLS inspection approaches. As you can see from the table, Passive TLS Mirroring offers a number of unique advantages.

Does not affect availability or performance
TLS Mirroring in the cloud & on-premise
End-to-end encryption
Transparent to monitoring system or IDSPartial
No additional key management/vulnerability
No additional cryptographic operationsPartial
Comparison of TLS inspection approaches

An inline appliance whether it is a Man-in-the-middle (MITM) appliance or a web load-balancer such as Nginx affect performance and reliability. Even though these systems can mirror the clear text, (1) they are not available or difficult to implement in public clouds such as AWS and (2) are not transparent to the endpoints and the monitoring systems.

Ephemeral session key extraction and distribution shares some of transparency properties of passive TLS mirroring but suffers from the operational burden of (1) having to distribute potentially thousands of keys per second in a timely fashion to the IDS system and (2) forcing the IDS system to decrypt TLS packets (in addition to the all other traditional functions) . Obviously, the ephemeral keys (if leaked) can compromise forward security (someone can record the TLS traffic and later decrypt it with the ephemeral keys) thus introducing an additional security risk.

In summary, we believe that Passive TLS Mirroring has significant practical advantages over existing solutions (especially in cloud-based deployments).

How to get it

We offer passive TLS mirroring as an add-on to the MetaFlows Security System or as a stand-alone offering to augment any existing traffic monitoring systems. Passive TLS mirroring installs in minutes on any main-stream Linux distribution and recent Windows versions.

Please contact support@metaflows.com for further details and a trial.

Leave a Reply

Your email address will not be published. Required fields are marked *