Blog :: Network Operations

How to Use Flow Data as an Alternative to SSL Decryption


NetFlow has traditionally been limited to exporting fields contained within a packet header. With the influx of Content Delivery Networks (CDNs) like Akamai, Level3, Amazon, etc., it is hard to know where users are actually going. The obscurity caused by CDNs is further compounded with the transition to 443 as a transport for most web traffic.

Look at the connection below. From this vantage point, it is impossible to know what webpage the user was actually going to; we need to add more context into this flow export!

Cisco AVC will help add context

The Solution:

If we approach the problem practically, we know there are some hints to the user’s true destination hidden in the setup of the initial TLS handshake.

If I make a web request to the popular website Reddit and observe the data transfer in Wireshark, I can see that the SSL common name for is passed to my computer in a certificate prior to encryption taking place.

Extract the SSL common name with NetFlow

All we need to do is configure our router to include SSL common name in its flow exports and we have gained the additional context needed to figure out what our end users are up to.

The Configuration:

Cisco Application Visibility and Control (AVC) gives engineers the ability to design customized flow records with all sorts of rich metadata. First, let’s look at each step needed individually, and then I will provide a cut-and-paste configuration for convenience.

Step 1: Create the Flow Record

Command: flow record type performance-monitor scrut-avc-ssl

The record is the part of the configuration where we define the elements the router will send in its flow exports. If you are familiar with Flexible Netflow configurations, you will notice a slight difference in the above command. Make sure to specify “type performance-monitor” for this record; the “scrut-avc-ssl” is simply the name I am giving to my record.

Step 2: Create a Flow Exporter

Command: flow exporter sslexp

The exporter defines elements like the destination IP address and transport port for the flows.  You will see more information in the detailed configuration I included, but it is important to use IPFIX as the export version and include option tables—performance monitors require those settings.

Step 3: Create a Flow Monitor

Command: flow monitor type performance-monitor scrut-ssl-mon

The flow monitor is where we bind together the flow export and the flow record. Again, we are deviating from a normal flow configuration by specifying the “type performance-monitor.” The cache entry size we specify in this portion of the configuration is variable; I start at 5000 and move up from there if I need more detail.

Step 4: Create a Class Map


class-map match-any sslmap <- drops us into a submenu and names our class map “sslmap”

match protocol ssl  <- specifies the match to be for SSL traffic only.

This portion of the configuration ensures that this monitor will only look at SSL traffic. There is no need to waste CPU cycles on traffic without an SSL common name associated to it.

Step 5: Bind the Class Map and the Flow Monitor to a Policy Map


policy-map type performance-monitor policy-ssl-mon <- drops us into a submenu, names our policy map

class sslmap <- binds our classmap to the policy map

flow monitor scrut-ssl-mon <- binds our flow monitor to the policy map

Now that we have everything we need, we can apply this policy map to the interface and start exporting data from the system.

Step 6: Apply the Policy Map to the Desired Interface

Commands (from interface configuration):

service-policy type performance-monitor input policy-ssl-mon

service-policy type performance-monitor output policy-ssl-mon

Celebrate! You are now monitoring SSL traffic and extracting the SSL common name within your flow exports.

Cisco AVC added common name to flow record

Thank you for reading; I hope you have enjoyed learning a bit about what is possible with Cisco AVC flow exports. Please contact Plixer support if you have interest in gaining additional context into TLS traffic. In future blogs I’ll provide detailed configurations on how to grab metadata like HTTP Host, Client Side Network Delay, Jitter, Packet Loss, and more!

As promised, here is a full configuration to help get you started:

flow record type performance-monitor scrut-avc-ssl
match ipv4 tos
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match interface input
match flow direction
match application name
collect datalink mac source address input
collect datalink mac source address output
collect routing source as
collect routing destination as
collect routing next-hop address ipv4
collect ipv4 dscp
collect ipv4 id
collect ipv4 source prefix
collect ipv4 source mask
collect ipv4 destination mask 
collect transport tcp flags
collect interface output
collect counter bytes
collect counter packets
collect timestamp sys-uptime first
collect timestamp sys-uptime last
collect application ssl common-name

flow exporter sslexp
transport udp 2055
export-protocol ipfix
template data timeout 60
option application-table timeout 60
option application-attributes timeout 60

flow monitor type performance-monitor scrut-ssl-mon
record scrut-avc-ssl
exporter sslexp
cache type normal
cache entries 5000

class-map match-any ssl
match protocol ssl

policy-map type performance-monitor policy-ssl-mon
class ssl
flow monitor scrut-ssl-mon