If you have never decrypted SSL/TLS using Wireshark... you have never really lived. There is nothing quite like being able to see exactly what is on the wire. Lync has some great debugging tools, but there are times, especially with web services, where I wish I could see more of what is being transmitted back and forth.
Now you are probably thinking this isn't anything special, I can do this with Fiddler.
Although Fiddler is a great tool, it doesn't work if you want to see what is happening with web services on Lync Phone Edition. It also doesn't work well if you want to see other packets along side the web services to correlate issues with STUN in Lync Web App. I would also argue that Fiddler became so popular because doing Wireshark decrypting in the past was not for the faint of heart and it got the job done. Good news is that when I recently checked on a new version of Wireshark, this process is immensely easier. Since I have a love for Wireshark already... I won't be using Fiddler any time soon.
This blog post aims to give you the tools necessary to see exactly what is on the wire, even when those packets are encrypted. Let's dig in...
Getting the Private Key
If you have ever installed OCS/Lync you are quite familiar with Certificates. I'm not going to go in to the detail of why and how certificates are used. You can read Wikipedia for that. Just know there is a key piece of information we need to do decryption in Wireshark and that little bit of goodness is a private key.
The private key is essentially the secret decoder ring that allows us to view what is in the packets as if they were not encrypted. So... how do you get the private key. That is quite easy as long as you have access to the server where it is stored.
Let me show you how...
Login in to the server where the private key is stored. This could be your reverse proxy or Lync Front End server. Which private key depends on where you client is and what servers they are communicating with.
Open up an instance of Microsoft Management Console (I prefer to just hit the run dialog box and type "mmc")
Next select Add/Remove Snap-in from the File Menu
Select Certificates and click "Add >"
Select "Computer account" and click "Next"
Make sure "Local computer" is selected and click "Finish"
You will notice a "Certificates (Local Computer)" displayed under Console Root. Click "OK".
Open up the Personal Certificate Store and Right-Click the certificate you would like to export (with the private key)
Look a wizard! Click "Next".
Select "Yes, export the private key" and click "Next".
Click "Next" (DO NOT select Delete the private key if the export is successful. It will ruin your day)
Give it a password you will remember and click "Next".
Keep in mind this password will be viewable in Wireshark so don't use you super secret passphrase
Give it a filename to store the certificate with private key. This should be a .pfx file.
Woohoo! Click "OK"
Decrypting Packets in Wireshark
Don't have Wireshark yet? Get it here. You will want a fairly up to date version for what I'm about to show you. 1.8.x or later should be good. As of writing this blog the latest stable release is 1.10.3.
So if you have tried to decrypt packets in the past, you have no doubt become good friends with openssl and all the different commands to pull out the RSA key so that Wireshark could show you all that unencrypted goodness.
Guess what... no need to go through all that pain anymore. You can have your cake and eat it too!!
Wireshark will take the .pfx file straight out of your windows box and pull out the key for you... on the fly. Don't you just love it when software gets new features that is actually useful?
So here is how you configure Wireshark to decrypt SSL...
Fire up Wireshark and before you start a packet capture (you can do this after you have a capture too) select "Preferences" under the "Edit" menu
Behold... the Preferences Dialog
Open up the "Protocols" header and scroll down forever...
Click on "SSL" and then click on "Edit" next to "RSA keys list"
Put in the IP address for the server you are communicating with (example: Reverse Proxy or Front End).
Then specify the port the traffic is communicating on (443 for https).
Next, what protocol you are expecting after the packets are decrypted (http in this example).
Select your .pfx file and finally type in the password you entered when creating the file.
If you didn't fat finger something you should get a RSA key list that looks like this.
Next you need to enter in a SSL debug file. When done click "OK".
Now you are ready to do a packet capture. One key thing to remember when decrypting SSL is that it does no good to start in the middle of a packet conversation.
You need to capture the initial key exchange otherwise you will get nothing.
Sometimes this requires a reboot because the client machine will cache SSL keys and won't do a full key exchange.
Here is an example of capture I did for Lync Web App
Here is the packet detail all laid out nicely for us
Here is the packet byte section
Notice down at the bottom you have several tabs. This indicates the original encrypted data in the "Frame" tab. Then the important bit is the "Reassembled SSL" tab which shows the complete data unencrypted and reassembled from multiple packets.
Not just for HTTP
Now you are probably thinking to yourself... if I can do this for https and technically Lync uses SSL/TLS for SIP... then I should be able to decrypt SIP as well... and you would be right.
Technically Wireshark can do this for sip.tcp, http. smtp, ldap, imap, pop, q931.tpkt (not sure about that one) and skinny.
Just go through the same process and instead of using port 443 and http for your protocol on the RSA key list, specify port 5061 and "sip" protocol.
Getting a good capture of SIP with Lync is a bit more tricky because you need to wait for a key exchange to happen. This can prove to be frustrating and most people just prefer to capture the SIP the old fashioned way using the Lync debugging tools. Which I agree with most of the time.
But there are a couple of instances where this technique can be handy.
- Capturing sip and/or http traffic (ever have EWS yellow triangle) from Lync Phone Edition devices which have notoriously hard to read logs.
- Capturing SIP traffic going through a Load Balancer (I know that is sooooo OCS 2007). Why? Because by the time it goes through the load balancer you can't figure out what the original endpoint was. Having view of the SIP packet details can help you troubleshoot connections where the Load Balancer might be the problem.
Feel free to make comments below on other ways to use this...
Want more Wireshark check out my other blog... http://blog.lyncdialog.com/2010/10/wireshark-tips-and-tricks-for-voipsip.html
Also check out a blog written by Matt Landis that also covers some quirks you might encounter... http://windowspbx.blogspot.com/2013/11/getting-started-with-lync-and-wireshark.html?utm_source=twitterfeed&utm_medium=twitter