CloudShark Support

Decrypt SSL Traffic

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.

RSA Server Keys

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.

Client Keylog File

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. The 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.

Following SSL streams

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.

Debugging SSL Decryption

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.

Potential Problems

Sometimes SSL decryption may not work as expected. Please check the following:

  • Make sure the decryption rule is valid, i.e. the address, port, protocol, or key must be properly configured.
  • Double check that the private key is in the right format and verify this is the correct key for the server.

Diffie-Hellman

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.

SSL With Diffie-Hellman

One potential work around is to reconfigure your server to exclude Diffie-Hellman based Ciphers.

SSL Session Reuse

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.

SSL Capture With Full Handshake

SSL Capture With Session Reuse

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.

RSA Key Storage

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.

About CloudShark

CloudShark is made by QA Cafe, a technology company based in Portsmouth, NH. Our passion for packet captures has grown out of our other product CDRouter.

Get in touch via our Contact us page or by following us on your favorite service: