30 June 2010

How to eavesdrop on HTTPS traffic

I had an intermittent problem with my web app: a test suite intended to verify that client-cert SSL* worked was failing. It wasn't failing because the client-cert SSL auth was broken. It was failing because of a 400 Bad Request with the message:

Your browser sent a request that this server could not understand.
Request header field is missing ':' separator.

Of course, since the connection was SSL encrypted, I couldn't easily to see what was going on.

Fortunately, wireshark has SSL decoding built in. It's a bit tricky to use, but this wiki page and this mailing list post explain what to do. Here's the short version:

1. If your server's SSL key isn't in a .pem file already, make one. Here's what I did:
openssl pkcs12 -export -in server.crt -inkey server.key -name "Server Certificate" -out server.p12 -passin pass: -passout pass:
openssl pkcs12 -in server.p12 -out server.pem -nodes -passin pass: -passout pass:

Note that there are no passwords on these keys -- this is my testbed server. If you have passwords on your keys, the steps may be different.

2. Tell wireshark about the .pem file. Go to Edit->Preferences, expand the protocols menu, and
pick SSL from the list. If your https server is running on localhost, port 443, enter ",443,http,/path/to/your/server.pem" in the "RSA keys list" box.

3. Assuming that you don't have SSLCipherSuite defined elsewhere (in which case, you might want to temporarily comment it out if it contradicts this one), add the following entry to your apache2.conf and restart apache:


That turns off Diffie-Hellman key negotiation.

4. Make sure that your browser is opening a fresh connection. In Firefox, closing the tab and opening a new one appeared to be sufficient.

5. Start the capture on the appropriate interface. If everything works, Wireshark will decode it. If not, go back to the preferences dialogue, set a debug file, and try again. Look in the debug file for clues---perhaps Wireshark couldn't read your key, for instance.

* It tried to read a trivial CGI script that just echoed back the SSL environment variables like SSL_CLIENT_M_SERIAL and SSL_CLIENT_VERIFY.

1 comment:

  1. Did you find out what was causing the 400's from Apache? I have the same issue and am looking for a solution.


About Me

blog at barillari dot org Older posts at http://barillari.org/blog