Some of my colleagues are going to make fun of me because I titled this blog, “How to Monitor SSL Traffic” knowing that I absolutely hate when people call Transport Layer Security, SSL. What I’ve learned, though, is that most people still call it by the old Secure Socket Layers name, or SSL. Anyway, I digress. In this post, as the title self-defines, I will show you how you can monitor SSL and TLS traffic using NetFlow and metadata from the devices on your network.
What is SSL/TLS?
To start, let’s give a brief description of what SSL/TLS is, and why it is important. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as “SSL”, are cryptographic protocols that provide communications security over a computer network. When you visit a website prefaced with HTTPS://, you are connecting to a website over either TLS or SSL (hopefully not SSL, though given all the security problems with all versions of SSL). This is important because the volume of encrypted web traffic is growing daily. As more traffic is being encrypted, there is less visibility to both network and security professionals. Or is there!
How do I monitor SSL traffic?
There are a number of network devices, many of which you already own, that can provide you with the data you need to see the encrypted traffic moving across your network. From a vendor perspective (and this isn’t a complete list by any means), there are a number of vendors that provide metadata relating to SSL/TLS. Gigamon, for example, can provide all the details of the SSL/TLS certificate. SonicWALL and Palo Alto can perform SSL DPI to decrypt the traffic at the edge and send the decrypted metadata like URL details to your NetFlow and metadata collector.
To give you a bit more context, let me walk you through how these vendors’ metadata exports can be used. To do this, let’s take a look inside Scrutinizer at our Gigamon reports.
Below, we have a dropdown of our Gigamon reports being sent to Scrutinizer from our Gigamon appliance. In this dropdown, we can see that we have information relating to URL details, SSL information, as well as SSL Version Count. Now, I call this report out specifically because, as I mentioned above, if you see any connections that are actually using SSL, you could have a security issue that should be addressed quickly. After all, SSL 3 was deemed vulnerable by POODLE back in 2014. I would hope you’ve patched applications using SSL 3 by now. If you haven’t, or you forgot one, this report can help you fix that.
In this report, it actually looks like we have a connection using SSL 3. That’s something we certainly want to look into.
If I drill into the “3.0” option and select the default report, I can see the conversation that was using SSL 3. In the case below, I now know that the connection from my internal machine 10.1.15.196 was connecting to an external IP over SSL 3. This is something that may be worth investigating, if it is a critical application that we are using.
Finally, if I take a look at the Hosts with URL report, I can easily see the URL details for the encrypted, SSL/TLS connections. This makes it much easier to know what was viewed, because we have an otherwise encrypted URL that provides us with the source for the content downloaded from our network users and applications.
Now, while I was using Gigamon as my example, keep in mind there are many vendors that provide the ability to give you SSL traffic details. Most Next Generation firewalls have this functionality, as do many taps, probes, and switching and routing appliances. If you are curious whether or not you can get these details from your devices, give your friendly support team a call; they would be happy to help you understand what type of reporting you can get from your devices.
I hope I’ve been able to shine some light into the dark and obfuscated world of SSL/TLS.
