One of the most difficult things to analyze is traffic that’s been encrypted. Some might say, well duh, that’s the idea isn’t it? We want it to be difficult for someone to peak into what we are doing on the web. Especially if its our private banking, financial type stuff, right?
Well, for those of us that are tasked with troubleshooting an applications performance over the wire, it adds an extra layer of difficulty to the mix, we not only need to figure out what that applications is doing to run so slow over a network, we now need to decrypt it before we can see the really important parts of the conversation, the packets payload and any encrypted header packets.
Fortunately there are ways to do it; you just need the right tools and the right pieces of the puzzle.
In this article I don’t plan to cover every last detail for decrypting and analyzing network traffic. I will just providing the basics and a high level overview of what is needed to get started. Later on I will write a detailed article on some of the finer points of analysis. But for discussions on cracking codes and decoding network traffic, you will need to go elsewhere.
So let’s get started with the right tools, what is it you need? First off you need a tool to capture and store the packets or frames to disk so that you can review them. Generally speaking this is called a sniffer. There are several utilities out there that can capture packets and save them off. In the *nix world you have TCPDump, generally installed with just about every distro’ out there. It allows you to capture data on a host machine that is involved in the conversation you are looking to analyze. In the windows world, it gets a little more complex. You have Microsoft’s own network monitor software or NetMon that can do both packet capture as well as some basic analysis. There’s also Windows ports of TCPDump one of the better ones called WinDump, it requires the installation of WINPCAP to function. These are all examples of free and open source software that can be used, but If you are lucky enough to have licensing to use it, OPNET has a capture agent that can be accessed remotely from any PC. This has the advantage of not needing direct access to the host machine to capture the packets you need for analysis.
Next you will need a packet analyzer; several come to mind, with the best known and most versatile being Wireshark. Wireshark has been around for years, it was previously known too much of us as Ethereal, but changed names about 5 years ago. The best thing about Wireshark is its FREE! Yes there are others out there that do all kinds of neat stuff, such as OPNET’s IT Guru suite and its ACE (Application Characterization Engine) or Wild Packets EtherPEAK. But both carrier hefty price tags and are generally only for those of us that work in the corporate world in IT departments with deep pockets.
So now we have the basic tools needed, now what? Well now we need some help from the server group; you will now need to beg your servers admin to export the Private keys from the host servers who’s traffic you need to analyze. Without that you are pretty much up a creek without a paddle, unless you happen to have a Cray super computer in your back pocket. To export the keys from a *nix machine is pretty simple, generally they will just need to find a file with the .key or .pem extension defined in their web server/ application servers configuration, tar it up and ship it off to you. For windows systems of course it’s a little more tricky, to export from a windows system they can follow the directions in this Microsoft KB article – http://support.microsoft.com/kb/232136 .
Once you have these files in hand, you will need to convert them to PEM format using OpenSSL. While this might sound difficult its not really to bad, you will need to get yourself a copy of OpenSSL for windows, if you are working on a windows machine, or simply use the OpenSSL installed in most *nix distro’s. Then from a command prompt –
Openssl pkcs12 –in filename.pfs –nocerts –out key.pem
If it completes successfully you are done, if you needed to enter a password then you will need to do it with the –nodes flag. This will remove the password. Not very secure I know, but otherwise it’s a pain to use the key in most analysis tools, including Wireshark.
Now you need to configure your tool to use the private key, for Wireshark, go into the preferences -> protocols -> SSL. Give Wireshark the details of where the file is and when to use it.
So you would do something like this:
Ip, port, protocol, Directory of the file
0.0.0.0, 443, http, C:\{directory}\{filename}.pem
So now you have the tools, now you need to actually capture some packets, well, its not as easy as you might think. To get any of the analysis tools to decode the packets for you, you will need to get the very 1st part of the entire encrypted conversation. This means you will need to get the encrypted handshake. The handshake is a multi-step process that involves exchanging public keys and agreeing on ciphers. If you are lucky to capture that traffic, the tools should do the rest of the work.
So that’s the basics. Now we just need to figure out what its doing to make it run so slow. ;-)