« June 2010 | Main | August 2010 »

13 posts from July 2010


Disabling TLS Renegotiation in Apache

Let me begin by saying "Don't do this unless you are absolutely certain of the nature of ssl connections connecting to your Apache servers!"  OK, with that out of the way, if you need to disable TLS Renegotiation on your Apache sites look to version 0.9.8m or higher of OpenSSL.  From my reading of the release notes, the only production quality version of Apache that is compiled with OpenSSL v0.9.8m is Apache 2.2.15.  This means that if you are still using version 1.3 or version 2.0 and SSL, it's really time to upgrade to 2.2.

Apache v2.2.15 binaries or source when compiled against OpenSSL v0.9.8m actually fixes the TLS renegotiation vulnerability.  If you download the source to compile it yourself and compile against a version of OpenSSL older that 0.9.8m, you will not have these fixes. Unfortunately, the fix needs to be available from the client that is RFC 5746-compliant as well so v2.2.15 introduces a new directive: SSLInsecureRenegotiation that will allow for backwards compatibility for those connections or applications that need them. Enabling this directive though re-introduces the TLS Renegotiation vulnerability however.

I'm maintaining a list of potential issues when TLS renegotiation is disabled on my post from last week. If your customers are not connecting to your apache servers using one of these methods, you should be ok and should not need to worry about setting the SSLInsecureRenegotiation directive but for this upgrade, I do recommend spending more time on regression testing.

If you compile your apache implementation against OpenSSL 0.9.8l, you will completely disable TLS renegotiation. Personally, I would try to stay away from this.

If you need to enable old-style renegotiation, add the following to your SSL configuration on your apache servers:

    SSLInsecureRenegotiation on



Scanning for Unsafe URLs - Update 2

This post is sort of a big deal for me because it is the 300th post to this blog.  I'm happy to have reached this particular milestone and want to thank everyone taking the time to visit it and especially thank all of you who have subscribed to my RSS feeds and who are following the site updates on twitter. Additional milestones reached over the past week include an all-time high 75 subscribers to the blog's RSS feed.  This week, the Techstacks Howto's site should reach it's 10,000th page view since the site launched in September 2009 and sometime in August, this blog should reach it's 100,000th page view since re-launching under TypePad roughly 13 months ago.

Saturday's post about updates to my Tools site briefly touched upon BadUrlChk, which I will now cover in more detail here.

PCI Scanners are now testing for unsafe URLs.  The original "Scanning for Unsafe URLs" post introduced a Perl script, which is still a work in progress, that tests many well known, unsafe URLs that we web site administrators don't necessarily want exposed to the Internet-at-large.  Although I think Perl is really cool and I want to get really good at it, a lot of my scripts make use of additional CPAN modules that many folks don't want to necessarily install on their own personal workstations.  The scripts that I've written in groovy also make use of third-party modules.  The Techstacks Tools site exists as a hosted site for people who just want to run the test without having to worry about installing perl or groovy or any of the third party modules that I like to use.

BadUrlChk is a port of the Perl script from the original article.  The output is the same right now but it is running on Google AppEngine and makes use of the Gaelyk framework and HTTPBuilder.  All you need to do is plug in a URL and the scanner will output success or failure messages.  If you've got a vulnerability reporting that the ColdFusion Administrator console is open and running the tool confirms this, re-run the tool after remediation of the vulnerability.  It should then report that ColdFusion console access fails.

Presently, the script and the hosted version running on the Tools site are not completely ready and should be considered early beta.  You can get a pretty good idea of whether or not a small sample of well known, unsafe URLs are open to the Internet but the tools do not presently handle redirection well nor do they handle Authentication responses from the web server.  I'm still working on that.  Sites that redirect can result in a lot of false positives so I'm working on some false positive handlers as well.  

The nice thing about command line scripts is output is easy to handle.  The trouble with them is that they don't always translate well on a web site.  I'm working to see if there is a better way to display this output.

Apache 2.2.16 released

The Apache HTTP Server team announced the availability of version 2.2.16 of the apache web server.  The changelog lists 10 fixes and two of them are security fixes.  One of these security updates is a fix for a denial of service vulnerability affecting mod_cache and mod_dav.  The other is a security update for a proxy timeout detection issue on Windows, Netware, and OS/2 platforms.  Download it soon!