Skip to content

About

Introduction -- SSLSplit Beta

Note: SSLSplit is a proxy it can cause downtime if not setup properly.

The collectors have the capability to intercept and observe SSL traffic by using a trusted man-in-the-middle proxy. The proxy uses the packet forwarding rules on the instance (e.g. iptables) to intercept the SSL traffic. This feature is disabled by default.

How it Works

Here, we will provide an in-depth explanation of how the "trusted man-in-the-middle" approach works. To understand this, let us say there is a client (C) which is communicating with a server (S) using SSL. In order for Epoch Collectors to observe SSL traffic, the user needs to perform the following steps:

  1. The SSL proxy needs to be installed locally on the client host. The SSL proxy is based off of the proven, open source SSLsplit project. Let us refer to the SSL proxy as "P".

  2. The SSL proxy requires a certificate to act as a local Certificate Authority (CA). Either Epoch Collectors can use the pre-packaged self-signed certificate or the user can provide a certificate for which the private key is available to the SSL proxy.

  3. This SSL proxy certificate also needs to be added to the list of trusted CA certs on the client host.

  4. The iptables rules on the client host need to be modified to route encrypted traffic to the proxy (e.g. port 443 to the proxy port)

mitm

With the above setup, when the client initiates SSL communication with the server, the following steps happen behind the scenes:

  1. C -> SSL request is routed to -> P (due to the iptables changes)

  2. P terminates this SSL request from C. Instead P establishes a secure connection with destination service S.

    • That is, P -> SSL connection -> S

  3. Upon successful connection with server, P leverages its local CA certificate to generate a signed certificate for S. This certificate will have all the same defining attributes of S (subject DN, subjectAltName extension, etc.), except it will be signed using the local certificate we gave to the proxy during setup.

  4. Now, P will use the locally signed server certificate to establish an SSL connection with C. P is essentially masquerading as S.

    • That is, C -> SSL connection -> P

So in a nutshell, C -> SSL connection to -> P and P -> SSL connection to -> S. The proxy P has established itself as a trusted man-in-the-middle!

Local Packet Processing

The captured packets from SSL communication are locally processed by the Epoch Collector. Only the aggregated metrics (latency, throughput, etc.) and metadata (http.uri, http.status_code, etc.) are sent to the AOC for storage and analytics.

Incoming Calls and Trusted Certificates

SSLsplit comes with a pre-packaged self-signed certificate, which should be placed in the local CA store of the host. This ensures that the clients on the host trust the SSLsplit certificate.

However, this setup will only capture outgoing calls from the host. If you wish to capture incoming SSL calls, you will need to setup a different set of forwarding rules and provide a trusted certificate to SSLsplit. Instructions for this are given in each installation section.

For the most part, just capturing outgoing traffic should suffice, and will provide 100% visibility into your application. Only in certain edge cases would you need to capture incoming traffic.