ColdFusion Muse

ColdFusion and JVM Versions and SSLv3-TLS Security Magic

This is the second entry by Wil Genovese ( in our effort to provide a complete picture of how CF, Various versions of JVMs and various versions of SSL all work together. Wil's previous article on Surviving Poodle detailed a blow by blow description of how to troubleshoot a system broken due to the upgrading of SSL. This article includes some detailed technical information as well as the results of some painstaking tests. It is our hope that it will serve as a guide. It represents yet another reason to insure that you are upgrading to the latest JVM and CF version. Take it away Wil:

Wil writes...

We've all been taking steps lately to protect our computers and servers from the POODLE flaw in SSLv3. At CF Webtools we've been updating our servers in various hosting facilities to prevent the use of plain old SSLv3. As a reminder, there is base SSLv3, and SSLv3 plus TLS1.x. More about that later. Perhaps you never think about it, but as a ColdFusion developer you make frequent use SSL via various ColdFusion tags or cfscript. For example, CFHTTP lets you access a remote server (such as a web service) with a URL via ColdFusion server and it most often uses SSL in the process.

POODLE and ColdFusion

In case you missed why this is a trending topic (and why security folks like myself and the Muse are so riled up about it), here is a quick refresher as to what POODLE is according to US-CERT:

"All systems and applications utilizing the Secure Socket Layer (SSL) 3.0 with cipher-block chaining (CBC) mode ciphers may be vulnerable. However, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack demonstrates this vulnerability using web browsers and web servers, which is one of the most likely exploitation scenarios. "
"This affects most current browsers and websites, but also includes any software that either references a vulnerable SSL/TLS library (e.g. OpenSSL) or implements the SSL/TLS protocol suite itself."

In our case think of ColdFusion using CFHTTP to access a remote server over SSL. ColdFusion becomes the browser. Communications to the remote server (if vulnerable) could be compromised via Man in the Middle attack. This type of attack combined with the POODLE attack could lead to information exposer such as passwords or other authentication tokens that could then let an attacker access additional systems.

ColdFusion CFHTTP Under the Hood

How does ColdFusion create an HTTP request? CF uses an Apache Java class called HttpClient under the hood to do actual CFHTTP calls. The specific version was upgraded to Apache HttpClient 4.3.3 for ColdFusion 11. I found this information in the notes from a bug report I created for ColdFusion 10. ColdFusion 8, 9 and 10 all use an older version of this library so there is a notable difference in behaviors. The basic rule is that the older version of HttpClient does not appear to allow SSL fallback to older SSL versions. Here's how I developed this data:

Testing Methodology

To test for each possible case scenarios I used this simple code:

<cfhttp url="" method="GET" port="443">
<cfdump var="#cfhttp#">

And tested it against the following ColdFusion versions (and yes, at CF Webtools we run and maintain all of these versions for various customers):

  • ColdFusion 8.0.1 Fully Patched
  • ColdFusion 9.0.2 - fresh unpachted install
  • ColdFusion 10 Fully Patched
  • ColdFusion 11 Update 3 (Prerelease)
  • Java 1.6.0_04
  • Java 1.6.0_45
  • Java 1.7.0_71
  • Java 1.8.0_25

From my research I am finding that Java 1.6 is only capable of SSLv3 and TLS1.0 this is based on this article at Oracle. The table below comes from that article.

I setup each ColdFusion instance to use one of the specified Java versions for each round of testing. To verify the type of connection that was being made I used WireShark to intercept all network traffic and filtered for "ssl.handshake". This filter in Wireshark shows the exact handshake protocol that is used for the SSL connection. Here's a sample of wireshark output:

Based on the Oracle article noted above I used this Java arg in the jvm.config -Dhttps.protocols. This argument is supposed to specify the version of SSL/TLS allowed by Java. It can be used with any of the following values singly or in a comma separated list like so:


The possible values are:
  • SSLv3
  • TLSv1
  • TLSv1.1
  • TLSv1.2
According the the chart above only certain SSL protocols are available for each different Java version. The table below shows my results of each test for each Java version vs ColdFusion Version vs the Java argument that I used for the test. The value in the chart indicates the results of the test based on the captured request data in WireShark.

ColdFusion 8.0.1 ColdFusion 9.0.1 ColdFusion 10 ColdFusion 11
Java 1.6.0_04
TLSv1.0 TLSv1.0
Java 1.6.0_45
TLSv1.0 TLSv1.0 TLSv1.0
Java 1.6.0_45
TLSv1.0 TLSv1.0 TLSv1.0
Java 1.6.0_45
TLSv1, SSLv3
TLSv1.0 TLSv1.0 TLSv1.0
Java 1.7.0_71
SSLv3 Only
TLSv1.0 TLSv1.0 SSLv3
Java 1.7.0_71
TLSv1.0 TLSv1.0 TLSv1.0
Java 1.7.0_71
TLSv1, SSLv3
TLSv1.0 TLSv1.0 TLSv1.0
Java 1.7.0_71
TLSv1.0 TLSv1.0 TLSv1.2
Java 1.7.0_71
TLSv1.0 TLSv1.0 TLSv1.2
Java 1.8.0_25
TLSv1.2 TLSv1.2 SSLv3
Java 1.8.0_25
TLSv1.2 TLSv1.2 TLSv1.0
Java 1.8.0_25
TLSv1, SSLv3
TLSv1.2 TLSv1.2 TLSv1.0
Java 1.8.0_25
TLSv1.2 TLSv1.2 TLSv1.2


The most important finding is that no matter which value that I used for the -Dhttps.protocols argument with ColdFusion 8, 9 or 10 the resulting protocol that was used is the default protocol for that version of Java. In other words, for CF 8-10 this setting has no effect. Java 1.6 and 1.7 the default protocol is TLSv1.0 and I never could force CFHTTP to make a handshake with SSLv3. For Java 1.7 I never could get a higher protocol than TLSv1.0 to be used. For Java 1.8 the default protocol is TLSv1.2 and all attempts resulted in the SSL handshake using TLSv1.2 - again this is for ColdFusion 8 through 10.

ColdFusion 11 is where this story changes. CF 11 uses the newer Apache HttpClient. Consequently each result reflected the value of the -Dhttps.protocols argument. In cases where multiple protocols were given the highest possible protocol was used.


I think the following argument, -Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1, should be used to prevent SSL fallback to SSLv3 for ColdFusion 11. The older versions of ColdFusion do not need this argument because the default value for the given Java version is always used and that is never base SSLv3 (although interestingly you can force the use of base SSLv3 in CF 11 using the argument). The only caveat here is that Adobe may eventually update ColdFusion 10 with the newer Apache HttpClient. It is something we will certainly be pressing them to do. If they do then it will most likely be advisable to use the same argument settings for ColdFusion 10 in the future.

Interesting Side Note

Did you happen to notice the chart that I did get ColdFusion 9.0.2 to run on Java 1.8? That's interesting. I have not seen any notice from Adobe about there being an update for ColdFusion 9.0.2 to run on Java 1.8. I would not recommend trying this in production without extensive testing, but it's an interesting finding.

Muse Writes...

Thanks Wil! I know our readers will find this information incredibly valuable. If you are like me dear reader you tend to bookmark posts like this and return to them again and again as you stumble on to different environments. As always we welcome your comments and contributions to our compendium of knowledge.

Related Blog Entries

me's Gravatar So it's only SSLv3 we need to worry about on default settings?
# Posted By me | 12/9/14 5:01 AM
Damon's Gravatar What about running these tests against Railo? It would be interesting to see those results as well.
# Posted By Damon | 12/9/14 5:42 PM
Mark Kruger's Gravatar @Damon, I love that idea. I'm not sure we have every Railo version in a test bed. I'll see.
# Posted By Mark Kruger | 12/10/14 10:18 AM
Wil Genovese's Gravatar Currently is only SSLv3 that we are worried about. Older versions of SSL are already deprecated and Java 1.6, 1.7 and 1.8 won't don't allow the ssl2 protocol.

However, we are investigating a newly discovered flaw similar to POODLE in the various TLS versions being. So the older TLS protocols may be next for removing from use.
# Posted By Wil Genovese | 12/10/14 2:18 PM
Seth's Gravatar I was speaking with a rep at our host today (big CF host), and he mentioned that there was a cfhttpparam (I'm guessing type header) that could be added to determine the order of TLS authentication used for ColdFusion 9.02 on JVM 1.7.

Is anyone aware of such a header?

# Posted By Seth | 11/30/15 10:46 PM
Steven Rubenstein's Gravatar TLS 1.1 and 1.2 can evidently be enabled on Java 1.7 via the Configure Java option.

In Windows:
1. Click Windows Start button
2. Choose Programs : Java : Configure Java
3. Click on the Advanced tab
4. Near the bottom, check the checkboxes for TLS 1.1 and TLS 1.2

I was trying to fix this for a API call. We got an error about "Content is not allowed in prolog", but according to the SF TLS Help page, that means it is actually working correctly.
# Posted By Steven Rubenstein | 12/1/15 8:19 PM
Steven Rubenstein's Gravatar I forgot to mention that the server we tested this on is running CF 9.
# Posted By Steven Rubenstein | 12/1/15 8:20 PM
Seth's Gravatar Worth a shot, thanks!
# Posted By Seth | 12/4/15 2:22 AM
Hiroki's Gravatar It seems that CF10 Update 18 takes -Dhttps.protocols into account.
# Posted By Hiroki | 2/1/16 9:39 PM
John K's Gravatar Hello Mark, I realize I'm late to the game on this subject. But hopefully you can provide a little guidance. I've been getting the following TLS error when attempting to connect to Salesforce: "TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https". I'm running CF server 9.0 (no hotfix applied -- yet), so I know I definitely need to upgrade, but my question is, which upgrade? From the looks of your chart, I could possibly upgrade 9 which would give me Java 1.7. But again, from looking at your chart, I would need to download Java 1.8 to enable TLS 1.1 (and higher) protocols to work. And even in that scenario (Java 1.8 running on CF 9, with patches) could work, though your not sure about how it might work in production environment. So here's my real ask: Is it worth my time patching CF 9 and installing Java 1.8 in the hopes that it "could" work; or am I better off biting the bullet and upgrading from CF 9 to CF 10 or 11 (or whatever you'd recommend, if this is the scenario you would push). Sorry, I know this turned out to be a big question! Appreciate any insight or thoughts. Thanks!
# Posted By John K | 9/1/16 1:23 PM
Byron Mann's Gravatar Also have a few sites on CF8 that I support and beginning to see more issues with CF8 as certificates are coming up for renewal. I started working around it using wget.
# Posted By Byron Mann | 9/9/16 7:50 PM
Adrian Moreno's Gravatar Ran down this and some other posts to discover that CF 9 will ignore "-Dhttps.protocols=TLSv1.2" for every version of JDK 7 until JDK 7u171 b31, but then JDK 7u181 enables TLSv1.2 by default.

The only hurdle is that any JDK past 7u80 is behind an Oracle paid support wall. I managed to find someone with access and it tested just fine using PayPal's TLS Test site:

<cfhttp url=""; result="test">

<cfdump var="#test#">

JDK 8u172 will also work with CF 9.0.2 w/ all hot fixes, but I'd rather not risk the regression testing jumping to the next major version.
# Posted By Adrian Moreno | 6/11/18 7:20 PM
Wil Genovese's Gravatar It was nearly four years ago when I did this testing and wrote this article. Those Java versions were not available then. And as you pointed out you have to pay for those newer Java 1.7 versions. But I do thank you for that information. It's good to know.

As far as running Coldfusion 9.0.2 fully patched on Java 1.8, I've had mixed results. I never recommend anyone do that, but I've had the chance to work on systems where this has been done and had to troubleshoot issues that we eventually chased down to running on Java 1.8.0_nn.

The best answer is to upgrade ColdFusion versions.
# Posted By Wil Genovese | 6/11/18 8:02 PM

Blog provided and hosted by CF Webtools. Blog Sofware by Ray Camden.