Logging SSL

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] --- Johannes B. Ullrich, Ph.D. STI\|Twitter\|LinkedIn	Johannes 3908 Posts ISC Handler Oct 16th 2014
Subscribe	Oct 16th 2014 5 years ago
Would this be a worthy candidate for DShield? 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?	dotBATman 64 Posts
Quote	Oct 17th 2014 5 years ago
Bro makes it trivial to monitor for SSLv3 (or any other version or cipher): https://twitter.com/0xxon/status/522166644659875840 http://blog.securityonion.net/2014/10/new-securityonion-web-page-package-adds.html	DougBurks 6 Posts
Quote	Oct 17th 2014 5 years ago
Here's a syntactically correct line for nginx: <code>log_format ssl '$remote_addr "$http_user_agent" $ssl_cipher $ssl_protocol';</code>	DougBurks 1 Posts
Quote	Oct 17th 2014 5 years ago
If you're in an environment where you have good security controls such as web app firewalls and IDS/IPS, be VERY careful before following the pundits advice about ciphers, particularly the advice to enable Forward Secrecy. 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
Quote	Oct 17th 2014 5 years ago
Security Onion now includes queries to show SSL traffic grouped by version: 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	DougBurks 6 Posts
Quote	Oct 27th 2014 5 years ago

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

Johannes

3908 Posts
ISC Handler

Oct 16th 2014

Would this be a worthy candidate for DShield?
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?

dotBATman

64 Posts

Bro makes it trivial to monitor for SSLv3 (or any other version or cipher):
https://twitter.com/0xxon/status/522166644659875840
http://blog.securityonion.net/2014/10/new-securityonion-web-page-package-adds.html

DougBurks

6 Posts

Here's a syntactically correct line for nginx:

<code>log_format ssl '$remote_addr "$http_user_agent" $ssl_cipher $ssl_protocol';</code>

DougBurks
1 Posts

If you're in an environment where you have good security controls such as web app firewalls and IDS/IPS, be VERY careful before following the pundits advice about ciphers, particularly the advice to enable Forward Secrecy.

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

Security Onion now includes queries to show SSL traffic grouped by version:
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

DougBurks

6 Posts