CSAM: SSL Request Logs

Published: 2013-10-09. Last Updated: 2013-10-09 18:01:10 UTC
by Johannes Ullrich (Version: 1)

Today you may have noticed that the ISC website was down for a few minutes. This was the result of tuning our SSL configuration a bit. Configuring SSL is a bit of a balancing act. First of all, you want to configure SSL as secure as possible, which means limiting yourself to the hardest and most modern ciphers, secondly, you want to make sure that all of your users are still able to connect and that you are not loosing any old browsers that you still need to support. There are hundreds if not thousands of possible combinations (Operating system, browser, ssl library version), which does make it hard to predict what is going to happen.

Luckily, web servers like Apache have a feature to log what cipher is negotiated for a given connection.

In order to enable this feature, you use the "CustomLog" configuration directive. I am using:

CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x %{User-Agent}i

This will log the access time (%t), the client IP address (%h), the SSL protocol ( %{SSL_PROCOL}x ) the SSL cipher ( %{SSL_CIPHER}x ) and the user agent. You could just add this to your normal access log as well, but I prefer to keep it in a separate log.

Here are a couple of lines from the log:

[09/Oct/2013:17:46:21 +0000] x.x.x.x TLSv1 AES-256 Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Win64; x64; Trident/6.0)
[09/Oct/2013:17:46:21 +0000] y.y.y.y TLSv1 AES-256 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
09/Oct/2013:17:54:28 +0000] z.z.z.z TLSv1 RC4 Motorola

And you will see failed connection that did not manage to negotiate a connection:

[09/Oct/2013:17:44:40 +0000] a.a.a.a - - - "-" -

[09/Oct/2013:17:47:18 +0000] b.b.b.b - - - "-" -

[09/Oct/2013:17:49:23 +0000] c.c.c.c UNKNOWN - - "-" -

[09/Oct/2013:17:53:23 +0000] d.d.d.d UNKNOWN - - "-" -

Sadly, you will not be able to log what ciphers the respective user attempted. In order to obtain that information, you will need to capture full packets and analyze the "client hello" message in wireshark or tshark. Or, if you have a non https site, you may be able to find the same IP address and at least guess what browser was used based on the user agent.

SSLLabs recently added a feature to show what ciphers different browsers are likey to use (or if there is a connection failure) . I find it very helpful to check my server once in a while with SSLLabs. But of course, you can only test publicly reachable sites with SSLLabs.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: csam 2013 ssl

0 comment(s)

ISC StormCast for Wednesday, October 9th 2013 http://isc.sans.edu/podcastdetail.html?id=3590

Other Patch Tuesday Updates (Adobe, Apple)

Published: 2013-10-09. Last Updated: 2013-10-09 00:18:10 UTC
by Johannes Ullrich (Version: 1)

3 comment(s)

Adobe released two bulletins today:

APSB13-24: Security update for RoboHelp
http://www.adobe.com/support/security/bulletins/apsb13-24.html

I don't remember seeing a pre-anouncement for this one. The update fixes an arbitrary code execution vulnerability (CVE-2013-5327) . Robohelp is only available for Window.

APSB13-25: Security update for Adobe Acrobat and Adobe Reader
http://www.adobe.com/support/security/bulletins/apsb13-25.html

This update fixes a problem that was introduced in a recent update and effects Javascript security controls. As a result, only version 11.0.4 appears affected, no earlier versions. Only the Windows version of these Adobe tools are affected.

Apple released iTunes 11.1.1 today. The respective security page has not yet been updated, but expect a link to the security content of this update within the next day or so. http://support.apple.com/kb/HT1222 . This update only affects Windows. Patches for iTunes on OS X are usually released as part of OS X updates.

Did I miss any?

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: adobe apple

3 comment(s)