ISC StormCast for Friday, October 17th 2014 http://isc.sans.edu/podcastdetail.html?id=4197

Logging SSL

Published: 2014-10-16
Last Updated: 2014-10-16 16:37:52 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

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

Keywords:
5 comment(s)

Cisco Security Advisory: SSL Padding Oracle On Downgraded Legacy Encryption (POODLE) Vulnerability

Published: 2014-10-16
Last Updated: 2014-10-16 08:12:47 UTC
by Basil Alawi S.Taher (Version: 1)
0 comment(s)



Advisory ID: cisco-sa-20141015-poodle

Revision 1.0

For Public Release 2014 October 15 17:30  UTC (GMT)

+---------------------------------------------------------------------

Summary
+======

On October 14, 2014, a vulnerability was publicly announced in the Secure Sockets Layer version 3 (SSLv3) protocol when using a block cipher in Cipher Block Chaining (CBC) mode. SSLv3 is a cryptographic protocol designed to provide communication security, which has been superseded by Transport Layer Security (TLS) protocols. By exploiting this vulnerability, an attacker could decrypt a subset of the encrypted communication.

This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141015-poodle


 

Keywords:
0 comment(s)
ISC StormCast for Thursday, October 16th 2014 http://isc.sans.edu/podcastdetail.html?id=4195

Comments


Diary Archives