My day has ended in frustration the past two nights. Each nice I swore that I was abandoning my attempts to sniff the contents of SSL packets. And, just like the past two days, here I am, at it again. Loathe the problem unsolved.
The unsolved problem remains how to see the contents of SSL packets when I have the server's private key? Modern SSL v3 seems to baffle
ssldump, but I still hope this is possible. Since SPDY is a binary protocol, sometime I have to believe I am going to want to see that data. And since that binary data is built on top of HTTP / SSL, I need a means to get at that data.
I could relax browser SSL restrictions like a did a few days ago. But I really want to stick as close as possible to real, modern sessions. Besides, relaxing Chrome's SSL restrictions made it pretty much unusable for all other sites on the web.
My new weapons for today: Wireshark and Apache's SSLCipherSuite. I always prefer the command line to the GUI, but I am hoping that Wireshark will prove more adept at decrypting SSL than ssldump. Similarly, I hope than the Apache documentation will prove better than the openssl /
Starting with the Wireshark documentation on SSL, I note that it "only works for RSA key exchange if the RSA keys can be provided" (emphasis mine). I am still working with keys generated thusly with
openssl genrsa -out key.pem 1024In the Wireshark preferences for the SSL protocol, I add:
openssl req -new -key key.pem -out request.pem
openssl x509 -req -days 30 -in request.pem -signkey key.pem -out cert.pem
127.0.0.1,10443,http,/home/cstrom/key.pemThis comma separate list includes the IP address of the SSL-enabled server (localhost/127.0.0.1), the port (10443 is port-forwarded to 443 on my VM, the protocol (http), and the private server key that generated for Apache with
With that, I can start up a Wireshark session listening for
tcp.port == 10443:
In the top pane is the list of packets observed when I access my SSL-enabled VM. The middle pane has various attributes of one of the packets. The bottom pane holds the data contents of that packet.
And it is still freaking encrypted.
Before I get too frustrated, I recall that Wireshark asked for "RSA key exchange". Checking the SSL info in Chrome, I see:
Hrm... DHE-RSA key exchange sounds like RSA key exchange. At least it has the letters RSA in it. But referring back to the Apache documentation, I do not see it listed amongst the RSA keys. Lets see if adding something like
SSLCipherSuite DES-CBC3-SHAto the Apache SSL configuration will do the trick.
Now, when I reload the page in Chrome, I see that I am definitely using RSA key exchange:
But what really matters is what I see in Wireshark:
Glory Hallelujah! In the middle pane, I clearly see unencrypted SSL.
For good measure I try this again in
ssldump, which still fails to decrypt the data—most of the time. Every now and then (maybe one out of ten page loads),
ssldumpdoes manage to decrypt the data. But even then it takes tens of seconds to return the data. Clearly I am going to dump
ssldumpand move forward with Wireshark. I doubt it will replace my beloved
tcpdump, but it is definitely my go-to tool for SSL.
Before calling it a night, I give Wireshark a try on the NPN-enabled SPDY from the other night. It fails to decrypt the data, but I have a good handle on what needs to change to rectify that. I will pick back up with that tomorrow.
Ah, sweet progress.