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
Have you had any luck decrypting the SRTP streams to RTP for playback?ReplyDelete
That one is difficult. The crypto for encryption is exchanged in the sdp when the call is setup. This actually is one of those times where msft netmon/message analyzer works better because you can snif at the application layer by selecting a process like lyncReplyDelete
Also, in general, with rtp you can only playback g.711 and with a but more effort g.729. I haven't seen a way to do other types of coders... Especially RTAudioDelete
Any suggestions on capturing via OSX to a microsoft hosted Office365 server where afaik cert is not available?ReplyDelete
your best option is to use Fiddler http://fiddler2.com/ it will act as a web proxy and let you see what is being transmitted to the cloudDelete
Thank for your post...ReplyDelete
Actually I want to decrypt some packages that are sent by an android app on port 5061 (tls) so I connect my device to my computer with proxy(or an android simulator) and fiddler2 decrypt its packages but ssl packages not tls. Now when I search for its certificates I can find only a certificate with its api name not an IP that tls packages is sent by it. My question is how can i find that certificate ? and is there any other way to decrypt these android app packages
Fiddler is strictly a web proxy. If you actually have the cert with private key of the service you are trying to connect to on 5061... the only thing I can think of is to mirror a trunk port on your wifi access point/switch and get the traffic there. If you can do both of those you should be able to decrypt that traffic. Keep in mind you need to catch the key exchange before decryption will happen... so you will probably want to start your capture before you start communicating the first time on port 5061Delete
You know I'm just a client like the app and I just want to decrypt my messages that come to this app exactly what this app do as a client. Actually I could read all its packets on port 443 with fiddler and I didn't have anything, just fiddler did this :) but this app sends its messages through TLS 5061....now is there any way to decrypt 5061 packages like 443 (like fiddler)Delete
thanks for your help....
The only thing I can think of is to run your client through a Session Border Controller. But that is expensive... And a very complicated setup and the programmer may detect that it is in the middle and not allow that. I've seen TLS based communication care more then SSL as to checking the certificate. Sorry I can't help more.ReplyDelete
SBC? ARGH.. I have an SBC.. but all our traffic doesn't traverse thru it!! I just really want to capture my RTP traffic from Lync, via VPN, which is a call thru our Avaya Session Manager out to our SBC. Help! I feel I'm so close... yet SOOO far away!Delete
Well if you have MediaBypass turned off, that will force the media through Mediation server and you can capture it there.Delete
Jonathan, thank you so much for your post and comments is very visible you have a great experience on this.ReplyDelete
I had a trouble i think im solving thanks to you.