Wireshark is capable of decrypting SSL/TLS encrypted data in packets captured in any supported format.
This is an extremely useful Wireshark feature, particularly when troubleshooting within highly secure network architectures. This article examines the requirements and Wireshark configuration required to do so and provides some information on issues commonly encountered when using this feature.
Isn’t SSL/TLS Secure?
Don’t let this article give you the impression it’s not; as you’ll see from the next section, there’s a good deal of requirements that must be met. However, there are plenty of other reasons to consider it insecure. If you’re reading this article and you’re responsible for and care about the privacy and security of your traffic, please keep in mind that SSL/TLS, in reality, presents no more than a façade of security today; in the same way money apparently represents real value and different sex marriages normality and stability.
Ignoring our post-PRISM world for a moment (everyone is anyway right?); from a technical standpoint SSLv2 (regardless of the ciphers etc. used with it) is widely considered as insecure. You really shouldn’t be using it; however, don’t just use v3 or TLS and consider that enough to offer a good security posture. How it’s configured and the options and ciphers you allow (or not) are far more important, but that’s an article for another day.
Taking PRISM’s (and other country’s similar program’s) implications into account, frequent technical weaknesses exploited through techniques such as BEAST or BREACH, the ease with which a fake CA can be installed on most devices and the decidedly risky nature of ‘trusting’ any Certificate Authorities (CAs) after recent scandals and revelations, I’d have a hard time convincing anyone to use SSL/TLS. That is, if there was an alternative, which there isn’t. It probably doesn’t matter anyway, why try and break encryption when you can just knock on the door and ask politely like most government agencies and police forces can in some form or other.
I use self-signed certificates for the on-line services I run for myself; there’s a reason I run them myself. Any false security I may have had around any large organisation (including government) being as fallible and poorly organised as the people within it and unable to consume the necessary volume of information to be effective without genuinely prohibitive expense has vanished in recent years. Again, you can read more about that in a later article; I’m far from a security pro so take this whole section with a pinch of salt.
I know this list seems pretty long; I don’t think that’s necessarily a bad thing; if you can’t meet all these requirements, you probably shouldn’t be attempting to decrypt the data. As ever, preparation is key; if you think you’ll need to do this even if just once a month, find out what you need to do to make meeting these prerequisites less onerous.
- On Linux systems WireShark must be compiled against Gnu-TLS and GCrypt, not OpenSSL or some other encryption suite; not something to worry about on Windows systems.
- The private key used to encrypt the data must be available on the system running Wireshark.
- The private key file must be in the PEM or PKCS12 format; if it’s not you can use OpenSSL to convert what you have as appropriate, just Google it.
- The private key file should only contain the private key, not the public key (aka the certificate). Files frequently contain both, check by viewing the file in a true text editor. You only need the text delimited by this;
- —–BEGIN RSA PRIVATE KEY—–
- —–END RSA PRIVATE KEY—–
Any PEM private key file must not have a passphrase.It seems this is no longer an issue.
- RSA keys must have been used to encrypt the data.
- The capture must include both ‘sides’ of a conversation. In other words, the capture must include the full client and server exchange.
- Important: The capture must include the initial SSL/TLS session establishment. In other words, the CLIENTHELLO and SERVERHELLO exchange. Beware captures taken where a session has been resumed. Ideally, ensure any capture either a) is of packets related to an entirely new device connecting or b) where a device that has already previously established a session is used, it is used after a considerable time after the last session was established.
- Important: Ensure the use of a Diffie-Hellman Ephemeral (DHE/EDH) or RSA Ephemeral cipher suite is not negotiated between the two hosts. This is indicated by the use of aServerKeyExchange message. There is no way to decrypt data where ephemeral ciphers are used.
Configuring Wireshark to Decrypt Data
In Wireshark click Edit>Preferences…
Select and expand Protocols, scroll down (or just type ssl) and select SSL
Click the RSA Keys List Edit… button, click New and then enter the following information;
- IP Address is the IP address of the host that holds the private key used to decrypt the data and serves the certificate (i.e. the decrypting host, the server)
- Port is the destination port used to communicate with the host that holds the private key used to decrypt the data and serves the certificate (i.e. the decrypting host, the server)
- Protocol is the upper-layer protocol encrypted by SSL/TLS, for instance, the protocol encrypted over a HTTPS web connection is HTTP
- Key File – select as necessary
- Password is the passphrase used to protect the private key file, if any
I believe a wildcard IP address of 0.0.0.0 and wildcard port of 0 or data can be used.
Optionally, enter the path and file name of a debug file that you might find useful in helping you diagnose any issues with the decryption. Note this may slow down the initial load of the capture file.
Then simply open the capture and, if you’ve met all the requirements, you should find the application data has been unencrypted. If the standard SSL/TLS port isn’t being used you may need to select a relevant packet and then click Analyse > Decode As… and then select SSL.
Allowing Others to Decrypt Without The Private Key
Thanks to Jens for his comments below around extracting the session keys from a decrypted capture; therefore avoiding sending a vendor or other party that you want to see the unencrypted data your valuable private key. To do this, decrypt the capture as detailed above and then click File > Export SSL Session Keys…, provide a file name and save to an appropriate location. You can then send this file, along with the capture to someone you wish to decrypt the captured data; all they then need to do is;
Load the capture in Wireshark and then click Edit>Preferences…
Select and expand Protocols, scroll down (or just type ssl) and select SSL
Click the Browse… button to the right of (Pre)-Master-Secret log filename and select the session key filename that you also sent to them.
Cloudshark also tweeted to say: “…in CloudShark you can keep your keys secure – decode without sharing!” I was rather dubious about the security (or rather lack of it) of providing keys to a cloud service but it turns out they now provide appliances. Thus your keys truly remain under your control and you can provide access to decoded captures without having to provide your keys. However, I assume this means you need to provide access to your appliance’s interface.
Notes & Issues
- Ensure you’ve met all the requirements listed earlier.
- Wireshark can only decrypt SSL/TLS packet data if RSA keys are used to encrypt the data. If a Diffie-Hellman Ephemeral (DHE) or RSA ephemeral cipher suite is used, the RSA keys are only used to secure the DH or RSA exchange, not encrypt the data. Thus, even if you have the correct RSA private key, you will not be able to decrypt the data with Wireshark or any other tool. You can check which cipher suite is being used by examining the Server Hello packet sent by the host that holds the private key, if the cipher suite specified begins TLS_DHE or SSL_DHE, you will not be able to decrypt the data. If the server sends a ServerKeyExchange message, you will not be able to decrypt the data. I’ve no idea how to prevent RSA ephemeral use. For DHE, your only option (if possible) is to modify either the client or server configuration so that DHE cipher suites are not used.
- For Firefox, enter this URL in the address bar: about:config, click the warning button and then enter this in the filter bar: security.ssl3.dhe. Set each preference displayed to:false and then filter again for security.ssl3.ecdhe and do the same again.
- Server side (not recommended), if using OpenSSL you could also change any configured cipher strings to include !DHE and !ECDHE
- With Java something like jdk.TLS.disabledALGORITHMS=DHE, ECDHE in the relevant place should suffice
- The issue detailed above may also occur with exportable RSA cipher suites (those using keys under 1024 bits in size) which you shouldn’t be using anyway.
- Wireshark can only decrypt SSL/TLS packet data if the capture includes the initial SSL/TLS session establishment. Re-used sessions cannot be decrypted; you can identify these as the server will not send a certificate or alternatively, the Wireshark SSL debug file will display assl_restore_session can’t find stored session error message.
- Ensure the IP address used in the RSA Keys List entry is the IP address as seen in the capture. Due to NATting this may not be the IP the client uses or the server’s real IP address.
- For Linux users, if you don’t have the RSA Keys List button available, it’s likely Wireshark was not compiled against GnuTLS. You can check this by running the command wireshark -v. The output should include GnuTLS and GCrypt, if it doesn’t, reconfigure Wireshark with –with-gnutls, recompile and reinstall.
- Check your PEM private key file contains the correct header and footer, as shown previously, and no others;
- Check your private key file is in the correct format: PEM or PKCS12.
- Update: Twitter just led me to this article from Dominic Tulley of IBM that suggests duplicate packets may also cause issues and prevent all relevant packets being decrypted. If you experience this issue, the answer is to use editcap -d to remove duplicate packets from the capture file.
This can be a real life-saver and it can also be a real pain; especially if you tell others you can do it and then find the capture you have isn’t suitable or DHE or similar is in use. Make sure you caveat what might be possible and ideally, avoid the need to do this at all, it’s better that way.
Just as an aside, on the subject of performance, try using ECXXX where you can, the performance is great. (For those using F5’s, I don’t think these are ‘native’ so probably that negates the benefits.)
- If you’re running Linux, also consider ssldump.
- If you’re trying to troubleshoot HTTP issues, you may be better off running iehttpheaders for IE or LiveHTTPHeaders for Firefox on the client browser. As noted in the comments below, you can also use the built in developer/debugging tools available in Chrome or Safari.
I’d highly recommend the free Crypto 101 course/book for those new to this subject (or needing to brush up).