how to debug an ssl connection?

I have a client application that connects to a web service over https. I need to "sniff" all the network traffic between web service and my client to check if everything is okay, i.e, i have to debug the connection.

I have tried Wireshark b开发者_运维百科ut since I do not have server private key, data shown on wireshark screen is, of course, encrypted.

Is there a way to observe ssl network traffic between my client and web service when I do not have access to server itself and therefore private keys and other related stuff?

Thanks in advance.

See this: Debugging SSL communications.

I know theoretically it can be done - you can setup a proxy that communicates with the target web-service, point your application to connect via this proxy. Its a known limitation - Https assumes you trust all proxy and certificates installed on your machine. Its a form of Man-in-the-middle attack.

See if Fiddler would be of some use.

Man-in-the-middle attacks

In a man-in-the-middle attack, the attacker intercepts user traffic to capture credentials and other relevant information. The attacker then uses this information to access the actual destination network. During the process, the attacker typically serves as a proxy/gateway that presents a false SSL VPN site to the user; this proxy/gateway passes whatever authentication the user enters on to the real destination site.

do you have python installed?

pip install mitmproxy

mitmproxy -p 1234

even a video for you

(by the way, i had to apt-get install python-lxml on debian squeeze after an apt-get update)

Burp Suite (even Free Edition) allows you to set a SSL "proxy", it will present a different certificate to your application and it will decrypt (and display) the traffic for you. And if you want to test with the server in localhost too it allow you to set the proxy too (something I have been unable to do with Wireshark in Windows, and Fiddler).

If you don't have access to the server's private key, there isn't much you can do to see what's being protected by SSL/TLS. (You'll get to see the initial handshake at least.)

If you have entire control on the client, you could write a fake server that would have a private key and certificate that you control, and that would relay everything sent by the client to the actual server. For this, you'd need to make the client trust your own certificate, hence you need control of the client. It might be easier to tweak the corresponding hosts file on the client to perform the DNS spoofing too, to make connections to the right host name go to your fake server instead.