I'm trying to inspect the traffic of a program (which is running on my computer) that uses SSL over TCP to a non-standard port. The traffic may or may not be HTTP traffic, likely isn't. Neither Charles nor Fiddler2 are able to detect the connection. How can I view the unencrypted traffic? Solution needs to work on windows 7.


Wireshark should be able to do it. However, the process is not as straightforward as you would have to scan the memory for the master secret.

Here is a tutorial on how to decrypt SSL without access to the master private key.

  1. Identify the master secret and corresponding session key. This can be found in the "Server Hello" portion of the SSL handshake.
  2. Configure Wireshark to use the master secret. Save the master key to a text file and configure wireshark to use the master secret file.
  3. Decrypt the encrypted malware SSL session. Open the pcap file, right click on the session and select "Follow SSL Stream".
  • Excellent tutorial, it would be nice if you outlined the procedure for doing it in the answer. Eventually, links to third party sites will be affected by Link Rot (en.wikipedia.org/wiki/Link_rot) Nov 24 '14 at 8:16
  • Turns out the traffic isn't run through SSL but I tried this out anyway and was able to find the master key using this tutorial, which is very cool. I'll mark this as the answer anyway since it does answer the question I asked.
    – Telanor
    Nov 25 '14 at 5:21
  • The tutorial link was defunct when I checked but an archived wayback version is available Nov 16 '19 at 13:07

If the software is using a fixed port and an hostname rather than IP to connect you could redirect the traffic to your local computer and use, e.g. ncat to remove and readd ssl, then inspect the traffic in between. Comment if you need more details.


Burp Suite can do this to MITM HTTP and HTTPS traffic.

This is very easy via Invisible proxy mode:

Normally, web proxies need to receive the full URL in the first line of the request in order to determine which destination host to forward the request to (they do not look at the Host header to determine the destination). If invisible proxying is enabled, when Burp receives any non-proxy-style requests, it will by parse out the contents of the Host header, and use that as the destination host for that request.

When using HTTPS with a proxy, clients send a CONNECT request identifying the destination host they wish to connect to, and then perform SSL negotiation. However, non-proxy-aware clients will proceed directly to SSL negotiation, believing they are communicating directly with the destination host. If invisible proxying is enabled, Burp will tolerate direct negotiation of SSL by the client, and again will parse out the contents of the Host header from the decrypted request.

Of course the application would need to trust Burp's root CA, and the certificate that is automatically generated by it (i.e. the application is not using pinning and it is using trusted roots from the OS level, not its own).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.