Passive TLS Mirroring In The Cloud

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 simple 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 openessl). 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
receive(security_context,encrypted_text) {
   send_to_agent(clear_text);    //added by MetaFlows

An application (1) sends data to the other endpoint by encrypting it first and then transmitting it and (2) receives data after decrypting the content coming from the wire. This exemplification generalizes the API of all TLS libraries in existence today.

As you can see, we simply provide the local MetaFlows agent 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 clear text http/1.1.

Passive TLS mirroring works especially well in cloud based deployments where the mirrored TCP/IP packets are sent (through an optional TLS tunnel) to an external monitoring system such as a remote IDS sensor. 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.

Cloud-based passive TLS mirroring

The diagram above shows the mirroring agents and the receiving agents in the same VPC. However this is not a requirement because the mirrored traffic is encpasulated using TLS and can be transmitted across networks. Also, VPC traffic mirroring is compatible with passive TLS mirroring but not required.

It is possible to replay the traffic to an interface that is also receiving traffic from a traditional switch or a VPC mirror thus merging two mirrored sources onto one interface (as shown in the diagram). To minimize contention in high-bandwith applications, if possible, we recommend replaying traffic to a separate interface and either bonding multiple mirror interface or specifying multiple interfaces when invoking the IDS.

On the server:

Each host instrumented with our passive TLS mirroring capability executes the agent as:

 sslcollector -I iface -t ip_address

Where iface is the network interface connecting the host to the Internet and ip_address is the ip address of the external system analyzing the mirrored TLS packets.

On the external system (for example hosting an IDS):

The system receiving passive TLS mirroring at ip_address would execute an agent as:

 sslcollector -C -o iface

The sslcollector receives the passive TLS mirror packets from multiple TLS mirrors and replays them to the local interface iface for inspection. Any passive monitoring system (for example an IDS) can then inspect the decrypted TLS (optionally transformed into HTTP/1.1) by opening iface in promiscuous mode without performing any decryption or having to fetch ephemeral keys in real time. Each sslcollector is able to receive and replay up to 2 Gbps (sustained) on a standard 8-core server.

Passive TLS Interception on-premise

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.

On-premise passive TLS mirroring

On the server:

Each server instrumented with our passive TLS mirroring capability would execute the agent as:

 sslcollector -I iface1 -o iface2 

Where iface1 is the network interface connecting the server to the Internet and iface2 is the interface replaying the mirrored TLS packets to the switch.

External System

The external monitoring system or IDS would not require any modification and simply receive passive TLS traffic by mirroring each of the replay ports originating from the servers

In a more port-efficient solution, multiple TLS traffic mirrors can be sent through optional TLS tunnels to an aggregation appliance. The appliance (basically a secured 64-bit Linux server) can then replay the aggregated mirrors from multiple servers to a single mirroring switch.

Scalable Passive TLS mirroring

Server command

Each server instrumented with our passive TLS mirroring capability would execute the agent as:

 sslcollector -I iface -t aggregator_ip

Where iface is the network interface connecting the server to the Internet and aggregator_ip is the ip address of the aggregation appliance.

Aggregation appliance

The aggregation appliance receives all the TLS mirrors and replays the traffic on a secondary interface:

 sslcollector -C -o iface 

Where iface is the name of the secondary interface connected to a mirroring switch.

Why Passive TLS mirroring

TLS interception is usually achieved by routing or proxying the encrypted sessions through an in-line security device which terminates the TLS session, decrypts the content and (optionally) re-encrypts it before communicating with the intended recipient.

This kind of interception technology has the following drawbacks:

  • Increase in latency
  • Cannot be mirrored in the cloud
  • Requires a high-performance appliance capable of real time Encryption/decryption
  • Decreased network availability due to failures or misconfiguration of the inline device (see for example this).
  • Additional key/certificate 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.
  • Man in the middle appliances do not handle certificate pinning.
  • Can introduce additional security threats.

TLS interception can also be achieved by extracting the ephemeral session keys from the TLS handshake and distributing the session keys to external monitoring systems that can decrypt the TLS traffic.

This kind of interception technology has the following drawbacks:

  • Requires additional CPU resources to decrypt packets
  • Requires a real time, dedicated session key distribution system that cannot be subject to temporary network delays for real time detection.
  • The out-of-band decryption infrastructure needs to be highly secure and increases the attack surface.
  • The session key database becomes a key vulnerability to the forward security for all the endpoints.
Passive TLS mirroring is more cost effective and more secure
  • The cost of passive TLS mirroring is lower than any other technique because it does not introduce additional cryptographic operations.
  • It does not require the deployment of a key management infrastructure. In our approach the footprint of the original system stays the same and there are no cryptographic keys floating around or additional certificates.
  • Because the TLS mirroring is passive, any failure of our system does not impact the normal availability of the TLS connections which can go on unimpeded. The worst that can happen in a passive TLS mirroring system is its inability to provide clear text.
  • We leave the original TLS end-to-end negotiation intact avoiding invisible and implicit trust relationships between the client and the server.

Compare Passive TLS mirroring

The matrix below compares important features of existing TLS interception approaches. As you can see from the matrix, MetaFlows' solution offers a number of unique advantages.

How to install 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 3rd party IDS or traffic monitoring systems.

Passive TLS mirroring installs in minutes on Centos or RedHat 7/8, Ubuntu 18.02/20.4 or Amazon Linux 2. We also offer limited functinality on recent Windows versions. Please follow these instructions to install and licensing information.