The ISA Firewall admin may spend a lot of time studying or troubleshooting HTTPS traffic in a secure web server publishing scenario.
Unfortunately for the ISA admin, troubleshooting or simply examine HTTPS through ISA for the published server is not that simple, since the traffic is encrypted and ISA’s logs, although they provide some information, in certain scenarios they might not help as this information may not be enough. In these cases, seeing inside the SSL tunnel may help.
As you may have noticed, I’m using quite a lot Wireshark. I’ve posted many times Wireshark captures’ screens for IPsec with ESP confidentiality set to NULL, from simple IPsec tunnel mode s2s to DMVPN, with Wireshark decoding the needed payloads.
But for HTTPS I’ve used a MITM “approach” in my articles, for example using Burp Proxy.
The fun part is that Wireshark can be used to decrypt SSL packets(not only HTTP over SSL aka HTTPS, also LDAPS, IMAPS etc.) for RSA key exchange and if you have the server’s RSA private key(and you have it, since you use ISA’s web publishing feature).
References:
http://wiki.wireshark.org/SSL
http://blogs.sun.com/beuchelt/entry/decrypting_ssl_traffic_with_wireshark
http://www.novell.com/coolsolutions/appnote/19321.html
http://support.citrix.com/article/CTX116557
You can access the SSL decryption options by clicking Edit and selecting Preferences:
Then, in the Protocols node, scroll till you find SSL:
As can be seen from above, we will specify the server’s IP address, the port on which the server listens and the path to the server’s private key. The file format needed for the server’s private key is PEM.
So we need some “HTTPS traffic” from a server published by ISA to see how Wireshark’s SSL decryption work.
In the bellow example, I’ve used ISA Server 2006 SP1 SE to publish Exchange 2003 OWA and RPC over HTTP(single listener on ISA, single back-end Exchange server). This is what I’ve had handy in my lab, and we can also take at RPC/HTTP. HTTP compression was not used on ISA.
During the configuration of ISA I’ve exported the certificate from the IIS server to a .pfx file and imported the certificate on ISA. And now I’m going to extract the private key from this file in the needed PEM format. I will use OpenSSL for this operation:
Note: The resulted private key is not encrypted, so be careful with it. You do not have to move this file to ISA. You can simply take the Wireshark captures on ISA or on the needed clients and then copy these captures on your machine for decryption. However, if you copy the PEM file on ISA, and configure Wireshark to use it, you will be able to “live decrypt” the SSL packets, if for some reasons you want to do this.
In this example, I‘m going to take the Wireshark captures on the client, a Windows XP machine, using IE6 for OWA and Outlook 2007 for RPC/HTTP. Also I’m going to use Wireshark on this client to decrypt the SSL packets.
Wireshark was configured as shown above, the server’s IP address is ISA’s IP address used to publish OWA and RPC/HTTP, the port is 443, the protocol is http and the server’s private key is owa.pem(I’ve specified the location of this file).
And here we go, for OWA, the first GET request from the client:
We can quickly filter this, by using the Follow SSL Stream option:
Scrolling through the capture, the credentials entered:
Observing within the capture my actions:
So things look pretty interesting, isn’t it ?
Let’s make it even more interesting, by looking at the captured traffic for RPC/HTTP. Things may become a little bit messy when we quickly follow the conversation, but we can make it through(this blog entry is not about troubleshooting/explaining RPC/HTTP, just want to see/spot some decrypted data).
A capture:
Another capture for RPC/HTTP, a misconfiguration on the client:
And another capture for RPC/HTTP with another misconfiguration on the client:
