SANS ISC: Logging SSL - SANS Internet Storm Center

• 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

With POODLE "behind us", it is time to get ready for the next SSL fire drill. One of the questions that keeps coming up is which ciphers and SSL/TLS versions are actually in use. If you decide to turn off SSLv3 or not depends a lot on who needs it, and it is an important answer to have ready should tomorrow some other cipher turn out to be too weak.

But keep in mind that it is not just numbers that matter. You also need to figure out who the outliers are and how important (or dangerous?) they are. So as a good start, try to figure out how to log SSL/TLS versions and ciphers. There are a couple of options to do this:

In Apache, you can log the protocol version and cipher easily by logging the respective environment variable [1] . For example:
CustomLog logs/ssl_request_log  "%t %h \"{User-agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x "

Logs SSL protocol and cipher. You can add this to an existing access log, or create a new log. If you decide to log this in its own log, I suggest you add User-Agent and IP Address (as well as time stamp).

In nginx, you can do the same by adding $ssl_cipher $ssl_protocol to the log_format directive in your nginx configuration. For example:

log_format ssl ''$remote_addr "$http_user_agent" $ssl_cipher $ssl_protocol

Should give you a similar result as for apache above. 

If you have a packet sniffer in place, you can also use tshark to extract the data. With t-shark, you can actually get a bit further. You can log the client hello with whatever ciphers the client proposed, and the server hello which will indicate what cipher the server picked.

tshark -r ssl -2R 'ssl.handshake.type==2 or ssl.handshake.type==1' -T fields -e ssl.handshake.type -e ssl.record.version -e ssl.handshake.version -e ssl.handshake.ciphersuite

For "extra credit" log the host name requested in the client hello via SNI and compare it to the actual host name the client connects to.

Now you can not only collect "Real Data" as to what ciphers are needed, but you can also look for anomalies. For example, user agent's that request very different ciphers then other connections that claim to originate from the same user agent. Or who is asking for weak ciphers? Maybe a sign for an SSL downgrade attack? Or an attack tool using  and older SSL library...

[1] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#logformats[2] 

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