The Decrypt SSL Traffic analysis tool allows users to decrypt SSL traffic within a capture file. SSL traffic can only be decrypted if the user has access either to the appropriate RSA key, or a client keylog file.
Note that RSA keys must be imported and shared by admin users. See the section on RSA key management in the Admin Guide for more information on adding and managing keys.
With a “Man in the Middle” HTTPS proxy you can configure a web client in a manner such that all of the HTTPS traffic is decryptable, even to real websites on the Internet. This scenario works well with CloudShark’s SSL Key Storage, described below.
The following applies if you have access to the server’s private RSA key used to encrypt the traffic.
To decrypt SSL traffic within a capture file, specific decryption rules must first be defined. A decryption rule specifies the IP address, port, protocol, and RSA key for an SSL-based stream or connection within the capture file.
Multiple unique decryption rules can be defined for each capture. Once a valid decryption rule has been configured and applied, the SSL traffic for that rule will be automatically decrypted and visible in the decode window.
If you do not have access to the private RSA key used by the server, it may be possible
to use key information gathered on the client side. Web browsers like Firefox and Chrome
are able to save keys used when visiting websites. Here is how to generate the SSL
keylog file using Firefox.
openssl command-line client is also able to generate a keylog.
The client keylog data can be pasted into CloudShark and used for SSL decryption.
Once an SSL session has been decrypted, CloudShark provides a tool for following SSL streams. This tool can be used to provide the familiar follow stream view for decrypted SSL streams. The Follow SSL analysis tool menu option will be active for captures that have SSL decryption rules applied.
Administrators have the ability to generate an SSL debug log to help them look for issues setting up decryption keys with traffic. Because this debug log can potentially expose private key information, this is only available to members of the Administrator group, and the resulting debug log is must be accessed by logging into the underlying OS. It is not delivered via the web.
To make the “debug log” button appear as an admin, you must first apply either an RSA Key or Client Keylog to the capture file, apply the changes, and then re-open the Decrypt SSL dialog box.
Sometimes SSL decryption may not work as expected. Please check the following:
You can not use decryption if a Diffie-Hellman based cipher is in use. Look at
the SSL exchange and look for the Server Hello message. This will normally
report the chosen cipher. If it contains a DH, then Diffie-Hellman is in use
and the decryption using the SSL server key will not work. For example view the
following capture using the filter expression
ssl.handshake.type == 2.
One potential work around is to reconfigure your server to exclude Diffie-Hellman based Ciphers.
You can not use decryption if your SSL session was reused and the full SSL handshake is not in your capture. If you are having trouble with SSL decryption and suspect SSL Session Reuse try using the following filter expression:
!ssl.handshake.session_ticket || ssl.handshake.session_id_length == 0
If any packets match this filter expresion it is likely that the SSL was used during this capture and the full handshake may not have been captured.
Here are a couple of example captures to show the difference between the full SSL handshake, and one where an SSL session was reused.
Here is also an article which describes SSL session reuse and includes a diagram to explain the handshake in both cases.
Possible work arounds to avoid SSL session reuse include configuring your server to disable SSL session reuse or clearing any SSL caches created by the client before capturing SSL traffic.
All RSA keys are ultimately stored on the CloudShark Appliance filesystem and only readable by the cloudshark OS user that does the actual decryption. A CloudShark web user does not normally have OS access.
Users should take all the normal security precautions you would for any server that has a key stored on the file system. There is always some risk that the base OS is compromised.