Inspecting and correlating TLS/SSL traffic in Windows

With the final deadline looming for PCI systems to use only TLS 1.2 (OK they allow better 1.1, but suggest you use ony 1.2 if possible), We had a few clients who were still using TLS 1.0. Enforcing just TLS 1.2 is easy, but not always the case if you still want all of your custom windows applications to still work. To this I started to use Microsoft Message Analzer to not just see what TLS/SSL protocols were being used, but also what processes were obstinently still using the older cipher suites.

I would like to preface that this is not the best way to run to preliminarily look for older SSL/TLS in your environment. If you just want to see what versions of TLS, but dont really care about finding the process, then you will have a much easier time running wireshark or seeing if your FW can detect ther version. Using tcpdump or Wireshark capture filter of "tcp port 443 and (tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)" will limit to TLS handshake traffic and is much easier to run for longer periods of time. Additionally Microsoft Message Analyzer requires A LOT of resources to parse a 250 mg trace. I would suggest 4 cores and 16 gigs of ram, and you should still expect to give the tool 30-60 seconds when loading or making major changes. I tried running MMA in my Azure instance (Standard D1: 1 core, 3.5 gigs ram) and I gave up after it spiked the CPU for 11 hours.

What MMA does have going for itself are two things. Being able to associate traffic with a process, and being able to natively capture traffic with installing any software on the server. This is a bonus in my use case as a change request process for PCI envrionments could delay troubleshooting.

Alright, lets dive into using this tool. Install MMA on a system you with plenty of CPU and moderate RAM. I would recommend not installing it on the server you want to investigate. Through MMA, you can run a remote trace if you have the right firewall rules in place, but I normally set up capturing the packets as a separate process.

On the system you want to investigate. Run an elevated command prompt. Then start the packet capture by typing netsh trace start capture=yes. This will start the trace and save to appdata\local\temp\NetTraces\ and default to a capture size of 250 MB. This can be changes by adding tracefile=(drive location)\(file name).etl and change the max file size by adding maxsize=###mb(warning, extending the size larger will tax MMA proportionally). The trace file will start and start capturing a lot of data. Depending on the amount of traffic in your environment, you can max the trace file rather quickly.

While we are waiting for the capture, lets make some changes to assist us win analysis in MMA. We are going to add aliases for expected IP addresses. This will let us see a nickname instead of the IP address. Well start the first view of MMA.

Then Click on Tools > Aliases > Manage Aliases

I haven’t found a way to start a brand new alias (small gripe), so right-click on the loopback address and select "Create a Copy"

Next Change the IP value to what you expect and give it the nickname you want. For this demo I only created the local IP and a gateway IP. In reality you would create aliases for the connections you expect the server will have. You’ll also need to go and check mark the alias you want MMA to enable.

Once you’ve waited an appropriate time, go back to the server and run netsh trace stop.

This will finish collecting data and once done provide two files. The primary .etl file mentioned in the output and a .cab file named the same way. Copy these two files to your local machine, load them in MMA and take a abreak. Wait till your cpu utilization stays below 80%, and expect MMA to take nearly 2 gigs of ram per trace you have loaded. Now we are ready to start investigating. Below is a picture of a newly loaded session.

Now we’ll add some filters and additional columns to make our job quicker. First we’ll have MMA show just TLS/SSL traffic of any version. The best filter is (TLS.records[0].version), however if you are looking for specific versions, you can also do (TLS.records[0].version) and (TLS.records[0].version.minor == 0) for SSL 3.0 or use (TLS.records[0].version) and (TLS.records[0].version.minor != 3) for all non-TLS 1.2 traffic. Refer to the table below for information on specifics.

Once you hit Apply on the filter, you should only see TLS traffic,

Because Module column will be just TLS and the Summary column wont caontain valuable data, we’ll go ahead and shorten the widths. I’ll then click on one of the "messages", Select IPv4 layer on the lower left window (Messsage Stack 1). Then right-click on the Source and Destination address in the "Details 1" window. And select "Add Source/Destination Address as Column". You’ll see MMA might also run recursive DNS. Then I’ll click on the TLS layer in "Message Stack 1", expand Records in "Details 1" and expand [0]. Now we will add version as a Column as well.

Everything up to now can be done in Wireshark, a tool I prefer over MMA almost every time. Now lets add process details. On the upper right is another window called "Field chooser". In its search bar, lets type process. You should see high up in the list will include, Process Command, Process ID, Process Name, and Process User SID under Global Properties.

I like to add the Process Name and Process Command. Once you’ve add these, you’ll notice that the ProcessName might include "Idle" or a "(#)". You’ll see idle when a packet is inbound to the system. Considering the nature of SSL/TLS, you can ignore these and filter them out if you would like. I have seen it sometimes also provides a false process as well for inbound packets. The the ProcessName field has a number in parentheses, then that is the process ID and the process ended before stopping the packet capture. If you have the proper auditing, then you can cross reference event logs for the process ID.

In the picture below, you can see two processes highlighted. WindowsAzureGuestAgent using TLS 1.2 and LF Intrusion Detection Service using TLS 1.0. At this point, I would confirm that tool has the capability to use TLS 1.2 and then research the proper solution.

Last thing I want to make you aware is if you are looking into an external facing IIS (w3wp.exe) or other website that is using TLs. Be aware that the external client might not be able to use TLS 1.2. In those situations, it helps to review the initial TLS handshake where you can see the client and server repsonses that includes what version they want to use to communicate. In MMA you would search for (TLS.records[0].fragment[0].body.client_version

If you would like more information on using MMA, check the following links.