Logging SSL
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]
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
Output could be a list of the most common / expected user agent / cipher combinations, a whitelist (kind of) that helps admins with finding the anomalies they should be focusing on?
Anonymous
Oct 17th 2014
9 years ago
https://twitter.com/0xxon/status/522166644659875840
http://blog.securityonion.net/2014/10/new-securityonion-web-page-package-adds.html
Anonymous
Oct 17th 2014
9 years ago
<code>log_format ssl '$remote_addr "$http_user_agent" $ssl_cipher $ssl_protocol';</code>
Anonymous
Oct 17th 2014
9 years ago
If you've uploaded your SSL certs to an IDS/IPS/WAF running in bridge mode or from a span port, enabling Forward Secrecy on the downstream devices instantly turns those devices blind. Why? Because Forward Secrecy is great at protecting individual transactions at the expense of security tools that need to decrypt the traffic on the fly.
A really good pen testing company or attacker will check to see if you have Diffie-Hellman ciphers enabled and if you do, they will configure their tools to use just those ciphers. Then they will push through a really noisy attack along the lines of "1 = 1" and see what happens. If they're not blocked, they know that either you do not have adequate protections in place or you do but they cannot handle the dynamic keys of Forward Secrecy and it is Game Over if you have a web app vulnerability.
Anonymous
Oct 17th 2014
9 years ago
http://2.bp.blogspot.com/-SP7EHYSMWwM/VE4nWXtBuyI/AAAAAAAAB-s/I7EA274OzeE/s1600/Screen%2BShot%2B2014-10-27%2Bat%2B7.01.04%2BAM.png
or by cipher:
http://2.bp.blogspot.com/-9EpYpMwPAdY/VE4nVW9nrpI/AAAAAAAAB-k/QM3LJg7GN0k/s1600/Screen%2BShot%2B2014-10-27%2Bat%2B7.01.44%2BAM.png
For more information, please see:
http://blog.securityonion.net/2014/10/new-securityonion-web-page-and.html
Anonymous
Oct 27th 2014
9 years ago