comment déboguer une connexion ssl?

Question

J'ai une application cliente qui se connecte à un service Web via https. Je dois « sniff » tout le trafic réseau entre le service web et mon client pour vérifier si tout va bien, i.e., je dois déboguer la connexion.

J'ai essayé Wireshark, mais depuis que je n'ai pas la clé privée du serveur, les données affichées à l'écran Wireshark est, bien sûr, crypté.

Est-il possible d'observer le trafic réseau entre ssl mon client et le service Web lorsque je n'ai pas accès aux clés serveur lui-même et par conséquent privé et d'autres choses connexes?

Merci d'avance.

Answer 1

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.

Answer 2

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)

Answer 3

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

Answer 4

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.