Using Wireshark to Decrypt WebSphere HTTPS/SSL/TLS Traffic
kgibm 0600027VAP Visits (9199)
Wireshark (formerly called Ethereal) is a great, free, open source tool to analyze network packet captures. To gather packet captures on various operating systems, see http
By default, WAS uses PKCS#12 or p12 files for the SSL key stores with the password of WebAS. In this example, I'll be looking at an SSL login of the deployment manager, so I've copied off the $WAS
First, gather the packet trace either on the client or on the server. Here I'm on Linux gathering everything on port 9094 (the SSL port of the deployment manager):
$ sudo tcpdump -i any port 9094 -w dmgr.pcap
Start Wireshark and go to Edit > Preferences > Protocols > SSL. Enter:
RSA keys list: CLIE
In my case:
RSA keys list: 127.
Load the capture file in Wireshark. You may see something like the following:
Frames 1 through 9 are the TCP and SSL handshakes. If the next frame on this stream says "Encrypted Handshake Message," then something went wrong. Looking at the SSL debug file, search for CIPHER:
$ grep CIPHER wireshark.out
Looking at the IANA.org list, we can see that this cipher is TLS_
Unfortunately, Wireshark does not currently support DHE: http
To remove DHE from available ciphers in WAS, go to SSL certificate and key management > SSL configurations > $SSL_SETTINGS > Quality of protection (QoP) settings. Under Cipher suite settings, select any ciphers in the Selected ciphers listbox that have DHE in them, and click << Remove. Click OK, save, and synchronize. You will have to gather a new packet capture after this is done.
Once you've got a packet capture with a cipher that Wireshark understands, when you load the capture, you should immediately see the "normal" Wireshark view, with HTTP traffic. In this case, frame 10 shows "Finished" instead of what we saw before:
In the bottom view, a new tab called Decrypted SSL data now shows up! In this case, we can see my user name and password being submitted on the POST to the DMGR admin console login page.
It's important to note that the SSL handshake must be captured for this to work, so if the packet captures starts and the user's browser re-uses a previous connection, the user will need to restart their browser or wait for that connection to naturally time out.