Who got the bad SSL Certificate? Using tshark to analyze the SSL handshake.
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 ;-) )
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
Anonymous
Mar 12th 2015
9 years ago
Anonymous
Mar 13th 2015
9 years ago