I'm doing vulnerability research on a client/server architecture that uses a custom proprietary protocol sent over SSL (port 443). I need to be able to intercept the traffic, and be able to view it in clear-text in something like Wireshark, modify the traffic and then send it to the server. The "client" is a Microsoft office plugin. My end goal is to be able to fuzz the unencrypted network communications.

I've tried generating a self-signed certificate with OpenSSL and importing the private key into Wireshark as a "data" protocol, but no luck. I still see the data as "Encrypted Application Data".

I've tried following these two links:

but they provide examples for HTTP. I am not sure if there's any difference, because this is a proprietary protocol (still sent over port 443).

My end goal is to be able to use a fuzzer, such as Sulley, to probe the server for vulnerabilities. Does anyone recommend a good way to accomplish this?

  • 4
    Why did you generate a certificate? Don't you need the server's certificate to import into Wireshark?
    – schroeder
    Jun 17, 2013 at 22:19

3 Answers 3


There's two ways to decrypt SSL traffic in-transit:

The first is to have the private key of the server. If you have that, you can feed it to wireshark which will do the rest. There are a handful of dedicated tools for this as well. But it can't be done without the server's private key.

The second is to MITM the connection. Fiddler will do this, as previously mentioned, and there are several industrial-grade tools that will do this as well. The catch is that you need to have a certificate that the client will trust. If it uses the standard Windows CA store, then adding your signing cert as a CA on the client computer should be enough.

The second option sounds more like what you want to do, and Fiddler sounds very much like the tool you're after, since "fiddling" with a connection is exactly what you're trying to do.

Note that if you're working with a custom protocol, what you're trying to do may involve writing some custom code. But it's possible.

  • Thanks for the reply. The difficult part to this scenario was that the server private key was encrypted on the server in a .cfg file, and required some reverse engineering to obtain. You couldn't simply export like you could a normal PKCS#12 or other cert/key format. Once I was able to export the private key, I imported it into Wireshark, and marked it as the "data" protocol, allowing for me to view the unencrypted traffic. Jun 20, 2013 at 18:27

You could try HTTP proxy debugger such as fiddler and Burp Suite, because HTTPS also send data over SSL layer, which is the same as your custom protocol over SSL layer. The proxy debuggers use man-in-the-middle approach so you must set Fiddler's certificate to be trusted by the client. You don't need to generate a certificate by using this approach.


Try tcpcatcher (free, Java), or see my answer to What's an easy way to perform a man-in-the-middle attack on SSL? for a short list of other tools and methods.

If you were able to get the server to use your self-signed cert, then you should be able to use Wireshark, but you must limit the ciphers so that an EDH key-exchange is not used (no PFS, and see the answer to Why different key exhange techniques for ssl key exchange? ). The first link you posted refers to using EDH in "Method Two" to prevent eavesdropping when Eve has the RSA private key.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .