Tshark/Wireshark SSL Decryption – Lessons Learned

This week Doug Burks and I needed to decrypt a few gigabytes of SSL traffic to find a TCP stream that contained a key word. We learned a bit along the way so I’m passing it along here.
First, full packet capture rocks. You are capturing EVERY packet that goes in and out of your network, right? Yeah, I know you have a HUGE internet pipe. But for a few hundred bucks you can have TERABYTES of drive space on an old laptop with DAEMONLOGGER running. I’d suggest something a little better, but you can make full packet capture work on a shoestring budget. Capturing the data is the easy part. Finding a needle in that haystack when it is all encrypted is the hard part.
SSLDUMP is one option, but I am really only interested in the text in the HTTP Payload and SSLDUMP give you a lot more information. We decided to use TSHARK because it has the ability to decrypt SSL and you can use Wireshark display filters.
We started out with something like this:
tshark -n “ssl.desegment_ssl_records: TRUE” -o “ssl.desegment_ssl_application_data: TRUE” -o “ssl.keys_list: 0.0.0.0,0,data,private.key” -o “ssl.debug_file: SSL-Decrypt.log” -r all.pcap -R “(tcp.stream eq 1)”
The first problem we ran into was the format of our private key. We had the right private key but every time we started tshark it recorded “unable to load PEM” in the log file. Long story short, ‘—BEGIN PRIVATE KEY ———-” and “——BEGIN RSA PRIVATE KEY—–” are NOT the same thing. Wireshark and Tshark want the private key in PKCS#1 format which is the “— BEGIN RSA PRIVATE KEY—” format. The other format is PKCS#8 format and Wireshark won’t load keys in that format. Step one was to convert the PKCS#8 private key to PKCS#1 format. Openssl does the trick:
openssl pkcs8 -in private.key -out rsaprivate.key -nocrypt
With our new PKCS#1 format private key (rsaprivate.key), the tshark command line became:
tshark -n -o “ssl.desegment_ssl_records: TRUE” -o “ssl.desegment_ssl_application_data: TRUE” -o “ssl.keys_list: 0.0.0.0,0,data,rsa_private.key” -o “ssl.debug_file: SSL-Decrypt.log” -r all.pcap -R “(tcp.stream eq 1)”
Now tshark’s log file no longer said “unable to load PEM”, but instead it said “key loaded successfully”. However, two lines down in the log we saw “couldn’t find key for this server, try the universal port 0 and the universal IP 0.0.0.0”.
This entry was a little confusing as we were already using the universal IP and port. So we changed that to the actual IP address and port of the server and BAMM… The next time we ran tshark the SSL-Decrypt.log file grew REALLY fast.
So how do we make tshark output HTTPS traffic as decrypted HTTP traffic in plain ASCII format (similar to tcpdump -A)? One option is to tell tshark to output the data field (data.data) using the “-T fields -e data.data” parameters. However, this output is in hex. We can pipe it to “xxd -r -p” to convert to ASCII:
tshark -n -o “ssl.desegment_ssl_records: TRUE” -o “ssl.desegment_ssl_application_data: TRUE” -o “ssl.keys_list:0.0.0.0,0,data,rsa_private.key” -o “ssl.debug_file:SSL-Decrypt.log” -r all.pcap -R “(tcp.port eq 443)” -T fields -e data.data | xxd -r -p
That seemed to work for us. Our SSL streams were dumping their payload in ASCII and we could find our string, but Doug (he is a bit of a perfectionist) changed the options to this:
tshark -o “ssl.desegment_ssl_records: TRUE” -o “ssl.desegment_ssl_application_data: TRUE” -o “ssl.keys_list:,443,http,rsa_private.key” -o
“ssl.debug_file:rsa_private.log” -r all.pcap -R “(tcp.port eq 443)” -V
By changing the 3rd parameter of the ssl_keys_list form “data” to “http”, tshark parses the decrypted packets with its HTTP parser. When the -V option is passed, tshark gives you a nice fully parsed unencrypted HTTP stream. Piping that through GREP works very nicely.
GET /index.html HTTP/1.1rn
[Expert Info (Chat/Sequence): GET /index.html
HTTP/1.1rn]
[Message: GET / index.html HTTP/1.1rn]
Request Method: GET
GET /images/logo.gif HTTP/1.1rn
[Expert Info (Chat/Sequence): GET / images/logo.gif
HTTP/1.1rn]
[Message: GET / images/logo.gif HTTP/1.1rn]
Request Method: GET

Join me for SANS 504 Hacker Techniques, Exploits and Incident handling in San Antonio November 15th! REGISTER TODAY BY CLICKING HERE!!!