SANS ISC: Who got the bad SSL Certificate? Using tshark to analyze the SSL handshake.

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Ever wonder if any of your users connect to sites with bad SSL certificates? I ran into this issue recently when debugging some SSL issues, and ended up with this quick tshark and shell script trick to extract the necessary information from a packet capture.

First, you may want to compare the host name your clients connect to, to the host name returned as part of the certificate. While the "Host" header is encrypted and not accessible, modern SSL libraries use Server Name Indication (SNI) as part of the SSL Client Hello to indicate to the server which site they are trying to connect to. The SNI option is sent in the clear to allow for name virtual hosting with SSL.

To extract the SNI fields, I use:

tshark -r file.pcap -Y 'ssl.handshake.type==1' -T fields -e ip.dst -e tcp.srcport -e ssl.handshake.extensions_server_name  | sed "s/\t/:/" > /tmp/ssi

The tshark command extracts all the SSL Client Hello messages (ssl.handshake.type==1) and then pulls out the destination IP, the destination port as well as the SNI field. I remove the first tab and replace it with a ":" to receive output like:

173.194.219.108:61879   imap.gmail.com

Your sed command will look a bit different if you are using OS X.

Next, we need to extract the host names advertised by the certificate that the server returns. This is a bit tricky as a certificate may either use a distinguished name (DN) or a subject alternative name if more then one hostname is included in the certificate.

tshark -r file.pcap -Y 'ssl.handshake.type==11' -T fields -e ip.src -e tcp.dstport -e x509sat.uTF8String -e x509ce.dNSName | sed  "s/\t/:/" > /tmp/in

Just like before, we now filter for certificate messages (type 11) and extract the source ip and the destination port, so we can match up connections with what we extracted above. The output should look like:

173.194.219.109:61898    California,Mountain View,Google Inc,imap.gmail.com    imap.gmail.com
173.252.101.48:61897    *.facebook.com    *.facebook.com,facebook.com,*.fbsbx.com,*.fbcdn.net,*.xx.fbcdn.net,*.xy.fbcdn.net,fb.com,*.fb.com,*.facebookcorewwwi.onion,facebookcorewwwi.onion,fbcdn23dssr3jqnq.onion,fbsbx2q4mvcl63pw.onion,*.m.facebook.com,*.messenger.com,messenger.com

Note how it is quite common to include a large list of hostnames.

Next, we need to link the two files. The "join" command is pretty useful here:

join -1 1 -2 1 -e 'empty' /tmp/in /tmp/out | tr " " "\t"

This will join the two files, pretty much how a SQL join would combine two tables, using the first column in each file as index. The output looks now like:

17.172.208.83:61878    *.icloud.com,icloud.com    p02-mailws.icloud.com
17.172.208.8:61881    *.icloud.com,management:idms.group.506364,Apple    Inc.,California    *.icloud.com    p02-ckdatabase.icloud.com
173.252.101.48:61897    *.facebook.com    *.facebook.com,facebook.com,*.fbsbx.com,*.fbcdn.net,*.xx.fbcdn.net,*.xy.fbcdn.net,fb.com,*.fb.com,*.facebookcorewwwi.onion,facebookcorewwwi.onion,fbcdn23dssr3jqnq.onion,fbsbx2q4mvcl63pw.onion,*.m.facebook.com,*.messenger.com,messenger.com    webdav.facebook.com

Making it reasonably easy to compare the requested host name (last field) with the names provided by the certificate.

(homework: a second script to analyze this output automatically, or a bro script to do all of this ;-) )

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn