ColdFusion Muse

Web Service SSL Issue: Trouble with Client Based Certificates

I was recently brought in at the 11th hour to an issue where a web service worked fine on an older 32 bit install of ColdFusion, but was not working on the new 64bit install. All the keystore certs were up to date and the client was scratching their collective heads. The web service in question used SSL and presented a client certificate. Now in order to do this in CF you have to manually construct your SOAP request and pass it as XML using CFHTTP. This is because only CFHTTP has an attribute for clientcert and clientcertpassword (as of CF 8 I believe).

In any case, the code our customer was using was straightforward. It assembled a soap request and then issued a call to CFHTTP like so:

On the "old" Coldfusion 8 "standard" server this worked fine. But on the brand spanking new, freshly patched and upgraded ColdFusion 8 enterprise server it was failing.

The Issue

The problem here is that a vulnerability in TSL (that's "SSL version 3.1" - see my previous post to learn more about the various SSL versions) was discovered in fall of 2009. This vulnerability allowed a "man in the middle" attacker to force a "renegotiation" of the handshake - thus allowing the insertion of arbitrary code into the request. Obviously this is a serious flaw. The fix was for vendors to simply disable the renegotiation feature in their products. So, for example, IIS 7 does not allow renegotiation by default.

So why is this issue not out there in the CF blogging world yet? First, I think that the use of client certs is a fairly small universe of ColdFusion applications. Second, Sun followed suit and fixed this issue with version 1.6.0_19 by disabling renegotiation. I think that many CF Servers are still using 1.6.0_18b or below - so this issue has yet to really rear its ugly head.

In any case, regular SSL requests continue to work as always with renegotiations disabled. A client certificate driven request is different however. It often requires renegotiation because of the complexity of the handshake (with 2 certificate pairs involved. That means client certificate driven CFHTTP SSL requests using the 1.6.0_19+ JVM will often fail to successfully negotiate a secure session. I want to say they will probably or certainly fail, but I'm not positive on that score.

The Fix - Such as it is

You have two ways of fixing this. You can roll back to 1.6.0_18. Seeing as how the current build is _20 you may not want to do this. Or, if you want to stay on 1.6.0_19+ you can add the following argument to your JVM.config file or files.

Obviously this allows for the server to renegotiate successfully. Your JVM will be vulnerable to the TLS exploit, but depending on your situation it may be a fairly low risk proposition. Still, you should take it into account. Consider running a separate JVM instance just for your web service. Some edge security devices can sniff out this issue as well.

Many thanks to my good friend and troubleshooting colleague Vlad Friedman from the Edge Web for figuring this out. I would also recommend that your read Chris Mahns blog entry on TLS Remediation.

Win2003 64 Bit Install Problems

This is a follow up to my post titled 64bit on Windows 2k3 Web Edition. In that post I did a play by play of an issue trying to install 64 bit ColdFusion 8 Enterprise on a Windows 2003 "Web Edition" platform. I have just finished a troubleshooting session with a nearly similar issue on Windows 2003 "Data Center" edition. If you have this problem you will know it because the install will silently fail after the files are extracted. Check in your temp directory and you will see a cryptic folder beginning with "I" containing two folders "windows" and "installdata". These 2 folders contain the extracted install files. Inside the "windows" folder you will also see an hotspot error log. It looks like "hs_err_pidXXX.log". You may have seen such files in your ColdFusion8/runtime/bin directory. They occur when the hot spot compiler has an unhandled exception.

Under the hood the ColdFusion install is firing off the "adobe_cf.exe" from that same windows folder. This exe file uses the adobe_cf.lax file as a launch settings file. Taking a closer look at the lax file and you will see some Java settings including two important settings. One is lax.nl.current.vm and the is lax.installer.win32.internal.property.0. Both of these settings point to a Java.exe file. By default the Java.exe file it points to is contained in that other temp folder called 'installerdata'. My guess is that the reason that the ColdFusion fails because the 64 bit JVM in the /installerdata folder is not compatible with something in the windows installation. In particular I think that there is a missing 64bit class or object.

The Fix

The fix is as follows.

• Download and install the 32 bit 1.6 JDK.
• Edit the adobe_cf.lax file to point to the java.exe file inside the jre folder of the newly installed 32 bit JDK.
• Run the Adobe_cf.exe file.

The install should fire up at the point of the first splash screen and follow through to completion. To be clear - you are still installing the 64 bit version of ColdFusion. Only the "launch anywhere" process will be running 32 bit.