There are primarily 2 ways of decrypting traffic with Wireshark:
- Logging client side SSL Session Keys
- Using the private key of the certificate presented by the server side of communications
The first has the advantage of being readily accessible, but it can only be used to look at traffic generated at your capturing client and with software that will write its session keys to the environment variable ‘SSLKEYLOGFILE’
Only RSA keys are supported, so you will need to turn off support for DiffieHellman suites on the browser (use Firefox or Chrome – Internet Explorer is not supported).
Newer versions of Wireshark do not require any alterations of SSL settings in the browser – just set the variable and start your browser!
The latter has the advantage of being able to decrypt any kind of traffic (as long as Wireshark has a dissector for it) – the downside is you need access to the server side private key (oops…. not always easy)
1: Let’s look at logging SSL Session Keys first:
You need to create the environment variable ‘SSLKEYLOGFILE’:
Control Panel -> System -> Advanced System Settings -> Environment Variables -> Add ‘SSLKEYLOGFILE’ and point to a file to store the session keys (sslkeylog.log). Avoid spaces in the file path!
Run the following command:
$ export SSLKEYLOGFILE=~/path/to/sslkeylog.log
Add it to your ~/.bashrc or ~/.MacOSX/environment (Linux or Mac)
to enable session key logging every time you log on to your system.
You MUST restart your browser for the new keys to take effect.
After tracing some https traffic just point the Pre-Master-Secret log filename under preferences of the SSL protocol to you sslkeylog.log
That’s it – Wireshark should now show you decrypted traffic!
2: Decrypting traffic using
the server side certificate private key:
Remember: this requires that you have access to the private key of the certificate used to encrypt the traffic. This key should under no circumstances get into the wrong hands, and it is therefore imperative that you handle this method with care!
It is also important to remember that SSL decryption will only work on RSA keys – DiffieHellman suites are NOT supported (neither are any ephemeral versions of RSA).This is due to the very nature of DH being ‘forward secret‘.
- Wireshark installation needs to be compiled with GnuTLS (not openSSL or bsafe). On Windows systems this will not be an issue, as Wireshark versions downloaded today will have GnuTLS-support built-in. Look for GnuTLS with Gcrypt in “About Wireshark”.
- only RSA keys are supported (not Diffie-Hellman).
RSA Ephemeral Suites are not supported either.
Most likely this will be a deal breaker as most servers today will choose DH and/or Ephemeral suites. To get around this issue you will need to reconfigure the server to prefer TLS_RSA suites:
Look at ‘Client Hello’ what Ciphers the client want and move the first RSA cipher in the list to the top of the server’s list of available ciphers – this is achieved using IISCrypto.
If you have access to the certificate private key I am assuming you have access to reorder ciphers as well.
- Server side private key needs to be presented to Wireshark as a base64 encoded .pem file without a password.
(Prior versions of Wireshark also supported the use of password protected PKCS#12-certificates, but this seems to have been removed in the later 2.x.x versions)
Also – the Public Key must not be part of the .pem key file.
- Important! The trace file must contain the initial SSL handshake – if the handshake was not captured in the trace, it will be impossible for Wireshark to decrypt the data within the SSL stream.
NOTE: this means that SSL Fast Reconnect/SSL Resumption will ruin your chances if the client reuses a previously negotiated ‘Session ID’ – look for this in the Client Hello packet. If this packet contains a Session ID, the client is trying to use Fast Reconnect. If the server responds with a ‘Session ID=0’ that means the server will not do SSL Fast Reconnect. If it answsers with the suggested client ‘Session ID’ – you are victim of SSL Fast Reconnect/SSL Resumption.
Extracting the private key to use for decryption:
Export the certificate w/private key from the server in question (if private key is unexportable – see the part about using MimiKatz below)
The certificate should be in .PFX format and choose a password to go along with the export (PS! Do NOT delete the private key after successful export!)
This will give you a .pfx file that you can name something like: C:\certs\server01_cert_w_pkey.pfx
You need OpenSSL installed on your local computer. See https://sourceforge.net/projects/openssl/
Copy this .pfx file to your local computer and run OpenSSL against it:
C:\OpenSSL-Win64\bin\openssl.exe pkcs12 -nodes -in C:\certs\server01_cert_w_pkey.pfx -out c:\certs\server01_key.pem -nocerts -nodes
This will give you the following file: C:\certs\server01_key.pem
Now remove the password from this .pem file:
C:\OpenSSL-Win64\bin\openssl.exe rsa -in C:\certs\server01_key.pem -out c:\certs\server01_keyclear.pem
This “server01_keyclear.pem” is the file that Wireshark will use for decrypting traffic that has been encrypted using the certificate you exported to begin with.
Using MimiKatz to get private key:
If the private key was marked as “Not exportable” when creating the initial CSR for the certificate you will have to use MimiKatz to extract it.
MimiKatz (http://blog.gentilkiwi.com/mimikatz) is recognized as malware by most virus protection software, so beware! You will need to “white list” the program to be able to run it.
The following Powershell (run as Admin) commands are used with Mimikatz.exe to extract all certificates + private keys from the local computer store:
This will create 2 files per certificate: .der & .pfx
Take the .pfx file and continue above with OpenSSL (the password on the .pfx file is ‘mimikatz’) to make the .pem file for Wireshark.
Info about SSL Session Key logging has been leeched from this link: