ColdFusion Muse

How to handle TLS1.2 for ColdFusion 9 and Older

The upcoming Authorize.NET switch to using TLS 1.2 only has a lot of people scrambling to get their servers updated. This has been a long planned transition at Authorize.NET and at many/most/all other payment processing companies. The inevitable facts are that TLS 1.0 and TLS 1.1 are outdated and they are going away. CF Webtools we have been preparing for this inevitable day for the past few years.

ColdFusion 9.0.n is not tested to work on Java 1.8 and I have had cases were certain features of ColdFusion 9 did not work with Java 1.8. I have not tried any older versions of ColdFusion on Java 1.8 and I'm not going to. Adobe has not certified any versions of ColdFusion older than version 10 Update 14 (or ColdFusion 11 Update 2 and older). All of that being said, there is a workaround that uses a 3rd party commercial solution to make TLS 1.2 connections from ColdFusion 9. It works well, but I do not recommend that as a long term solution. The preferred long term solution is upgrading the server(s) and ColdFusion version to currently supported versions. This way there will be security updates to help protect against new threats. The commercial third-party CFX tag will require recoding the CFHTTP calls for the new CFX tag. The tag is CFX_HTTP5 and it is available here.

Follow the installation instructions that comes with the download and then you will have to recode your CFHTTP calls similar to the examples below. The code examples are for the older Authorize.NET Advanced Integration Method (AIM) API calls that you are most likely using in your older ColdFusion CFHTTP calls.

<cfset authURL = "https://test.authorize.net/gateway/transact.dll" />
<cfif AuthNetMode eq "live">
<cfset authURL = "https://secure.authorize.net/gateway/transact.dll" />
</cfif>

<!--- CFHTTP Call - Your code might look something like this --->
<cfhttp url="#authURL#" method="post" result="cfhttp">
<cfhttpparam type="FORMFIELD" name="x_Login" value="#AuthLogin#">
<cfhttpparam type="FORMFIELD" name="x_Password" value="#AuthPassword#">
<cfhttpparam type="FORMFIELD" name="x_merchant_email" value="#AuthEmail#">
<cfhttpparam type="FORMFIELD" name="x_delim_data" value="true">
<cfhttpparam type="FORMFIELD" name="x_test_request" value="#x_test_request#">

<!--- we're using AUTH_ONLY so the card isn't charged until the order is processed --->
<cfhttpparam type="FORMFIELD" name="x_type" value="AUTH_ONLY">
<cfhttpparam type="FORMFIELD" name="x_method" value="cc">

<cfhttpparam type="FORMFIELD" name="x_amount" value="#orderTotal#">
<cfhttpparam type="FORMFIELD" name="x_card_num" value="#cardNumber#">
<cfhttpparam type="FORMFIELD" name="x_exp_date" value="#cardExpiration#">
<cfif isDefined("cardSecurityCode") and cardSecurityCode eq "">
<cfhttpparam type="FORMFIELD" name="x_card_code" value="#cardSecurityCode#">
</cfif>

<!--- If you want an email to go to the customer via authorize.net change this to true. Make sure authorize.net is configured properly. --->
<cfhttpparam type="FORMFIELD" name="x_email_customer" value="#x_email_customer#">

<cfhttpparam type="FORMFIELD" name="x_first_name" value="#billingFirstName#">
<cfhttpparam type="FORMFIELD" name="x_last_name" value="#billingLastName#">
<cfhttpparam type="FORMFIELD" name="x_company" value="#billingCompany#">
<cfhttpparam type="FORMFIELD" name="x_address" value="#billingAddress#">
<cfhttpparam type="FORMFIELD" name="x_city" value="#billingCity#">
<cfhttpparam type="FORMFIELD" name="x_state" value="#billingState#">
<cfhttpparam type="FORMFIELD" name="x_zip" value="#billingZip#">
<cfhttpparam type="FORMFIELD" name="x_country" value="#billingCountry#">

<cfhttpparam type="FORMFIELD" name="x_customer_ip" value="#cgi.remote_address#">
<cfhttpparam type="FORMFIELD" name="x_Email" value="#billingEmail#">
<cfhttpparam type="FORMFIELD" name="x_Phone" value="#billingPhone#">

<cfhttpparam type="FORMFIELD" name="x_ship_to_first_name" value="#shippingFirstName#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_last_name" value="#shippingLastName#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_company" value="#shippingCompany#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_address" value="#shippingAddress#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_city" value="#shippingCity#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_state" value="#shippingState#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_zip" value="#shippingZip#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_country" value="#shippingCountry#">
<cfhttpparam type="FORMFIELD" name="x_Description" value="#description#">
<cfhttpparam type="FORMFIELD" name="x_invoice_num" value="#invoicenum#">
</cfhttp>

<cfset response = cfhttp.fileContent>

To refactor your code you will want to do something like this.

<cfset authURL = "https://test.authorize.net/gateway/transact.dll" />
<cfif AuthNetMode eq "live">
<cfset authURL = "https://secure.authorize.net/gateway/transact.dll" />
</cfif>
<!--- CFX_HTTP5 Call - You'll want to refactor your code in this fashion --->

<cfset httpBody = "x_Login=#AuthLogin#&
x_Password=#AuthPassword#&
x_merchant_email=#AuthEmail#&
x_delim_data=true&
x_test_request=#x_test_request#&
x_type=AUTH_ONLY&
x_method=cc&
x_amount=#orderTotal#&
x_card_num=#cardNumber#&
x_exp_date=#cardExpiration#&
x_first_name=#billingFirstName#&
x_last_name=#billingLastName#&
x_company=#billingCompany#&
x_address=#billingAddress#&
x_city=#billingCity#&
x_state=#billingState#&
x_zip=#billingZip#&
x_country=#billingCountry#&
x_customer_ip=#cgi.remote_address#&
x_Email=#billingEmail#&
x_Phone=#billingPhone#&
x_ship_to_first_name=#shippingFirstName#&
x_ship_to_last_name=#shippingLastName#&
x_ship_to_company=#shippingCompany#&
x_ship_to_address=#shippingAddress#&
x_ship_to_city=#shippingCity#&
x_ship_to_state=#shippingState#&
x_ship_to_zip=#shippingZip#&
x_ship_to_country=#shippingCountry#&
x_Description=#description#&
x_invoice_num=#invoicenum#"
>


<!--- If you want an email to go to the customer via authorize.net change this to true. Make sure authorize.net is configured properly. --->
<cfset httpBody = httpBody & "&x_email_customer=#x_email_customer#">

<cfif isDefined("cardSecurityCode") and cardSecurityCode eq "">
<cfset httpBody = httpBody & "&x_card_code=#cardSecurityCode#">
</cfif>

<cfset cfxhttp = {}>
<cfset headers = "Content-Type: application/x-www-form-urlencoded">
<cfx_http5 url="#authURL#" method="post" out="cfxhttp.body" outqhead="cfxhttp.QHEAD" outhead="cfxhttp.RHEAD" ssl="5" body="#httpBody#" header="#headers#">
</cfx_http5>

<cfset response = cfxhttp.body>

The code is a minor change and relatively easy to do. I've tested this method in a production environment and it works fine. I do not recommend this as a long term solution. The preferred long term solution is upgrading the server(s) and ColdFusion version to currently supported versions. This way there will be security updates to help protect against new threats. If you are on ColdFusion 10 or 11 then the best option is to install the ColdFusion patches and upgrade the Java version to 1.8 then you will be good to go. If you need an experience ColdFusion developer to make these changes then please do contact us, we will be happy to assist.

The CFX_HTTP5 tag uses WinHTTP which is a built into Windows PROXY server. Here is where part of the problem exists. Microsoft didn't update WinHTTP on Windows 2008 Standard SP2. They've only updated it for Windows 2008 R2 and up. See this update (https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in). This leaves us not being able to use CFX_HTTP5 on Windows 2008 Standard and older.

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at cfwebtools.com.

CAVEATS:

  • This fix will not work for Windows 2003 Server, for any version of ColdFusion, as there is no support from Microsoft for TLS 1.1 or 1.2 in this server version.
  • This fix will not work for Windows 2008 Standard Server (not R2), for ColdFusion 9.0.n and older, as there is no support from Microsoft for TLS 1.1 or 1.2 for WinHTTP in this server version.

Authorize.NET Temporarily Ending TLS 1.1 and TLS 1.0 Support

At CF Webtools we have been preparing for this inevitable day for the past few years. We've been upgrading our clients servers and services to handle TLS 1.2 calls to Authorize.Net and other third party processors for a while now. Recently Authorize.Net announced a "Temporary Disablement of TLS 1.0/1.1" for "a few hours on January 30, 2018 and then again on February 8, 2018." This is in preparation for the final disablement of TLS1.0/1.1 on February 28, 2018.

As you may be aware, new PCI DSS requirements state that all payment systems must disable earlier versions of TLS protocols. These older protocols, TLS 1.0 and TLS 1.1, are highly vulnerable to security breaches and will be disabled by Authorize.Net on February 28, 2018.

To help you identify if you're using one of the older TLS protocols, Authorize.Net will temporarily disable those connections for a few hours on January 30, 2018 and then again on February 8, 2018.

Based on the API connection you are using, on either one of these two days you will not be able to process transactions for a short period of time. If you don't know which API you're using, your solution provider or development partner might be a good resource to help identify it. This disablement will occur on one of the following dates and time:

  • Akamai-enabled API connections will occur on January 30, 2018 between 9:00 AM and 1:00 PM Pacific time.
  • All other API connections will occur on February 8, 2018 between 11:00 AM and 1:00 PM Pacific time.

Merchants using TLS 1.2 by these dates will not be affected by the temporary disablement. We strongly recommend that connections still using TLS 1.0 or TLS 1.1 be updated as soon as possible to the stronger TLS 1.2 protocol.

This means that if you are using older methods to make calls to Authorize.Net that are not capable of making TLS 1.2 connections then you will NOT be able to process credit card transactions.

This affects ALL ColdFusion versions 9.0.2 and older! This also affects ColdFusion 10 Update 17 and older. If your server is running any of these older versions of ColdFusion and your server is processing credit cards with Authorize.Net then this advisory applies to your server.

CF Webtools has been successfully mitigating this issue for clients servers for the past couple years and we are very experienced in resolving these security related issues. In a previous blog post I tested which SSL/TLS levels were supported by various ColdFusion versions on various Java versions and produced an easy to read chart.

If your ColdFusion server is affected by this or if you do not know if your ColdFusion server is affected by this then please contact us (much) sooner than later. Our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at cfwebtools.com.

ColdFusion MailSpoolService Performance

In my last article about the Adobe ColdFusion MailSpoolService I mentioned that I was going to try to get specifics on expected performance in the Standard Edition vs Enterprise edition of the MailSpoolService. Adobe has not respond to my requests with actual data. While attending the ColdFusion Summit 2017 I tried to get a clear answer from any of the Adobe ColdFusion engineering team members that were at the conference. They didn't know the answer. Because I didn't get the response I wanted from Adobe I decided to start testing.

My first test was to setup a Windows VM with ColdFusion 11 installed with a standard license. I also created a simple CFML page that uses CFMAIL to send an email with a CFLOOP to send that same email a lot of times. To make this a more realistic test I made up a new disposable email address on our mail server at CF Webtools and sent the emails from my email server on AWS. This means that the ColdFusion MailSpoolService has to actually communicate with a mail server. SMTP connections can at times take time. The emails I generated have several paragraphs of Lorem Ipsum text to simulate actual email sizes. My first test was to verify one email did indeed get sent. It did. The next test was to send 1000 emails while timing with my iPhone's stop watch. We also have ColdFusion 11 Enterprise which meant I was able to test the performance against the Enterprise Edition. Lastly, I was asked to test on the Developer Edition because it is often stated that the Developer Edition is essentially Enterprise Edition with a two connection limit. I ran this test a couple times each from ColdFusion 11 Standard, ColdFusion 11 Developer, and ColdFusion 11 Enterprise servers.

Standard Edition
It took approximately 23 minutes to process 1000 emails in the mail spool. This comes down to about 44/45 emails per minute. Which works out to about 11/12 emails per 15 second pooling interval or 2600 email an hour. Which is a little more that 60,000 emails per day processing 24 hours straight without any connection issues. That's not too shabby for being the single threaded version of the MailSpoolService.

Developer Edition
After running the same tests a couple times in Developer Edition I got the exact same results as I did for Standard Edition.

Enterprise Edition
This is where you can say "You get what you pay for!". Before I go into the numbers let me also remind everyone that the Enterprise Edition of the MailSpoolService is multi-threaded and you can specify the number of threads. I think the default is 10 threads. This setting is in the Mail section of the ColdFusion Administrator Enterprise Edition ONLY in the sub section "Mail Spool Settings". There is nothing that indicates that there is a maximum number of threads. My tests are with 10 threads.

I had to run this test several more times just to make sure I saw what I saw. All 1000 emails were sent in a single polling of the mailSpoolService. That's 1000 emails sent in under 15 seconds. I ramped it up a bit and sent 5000 emails. This time it took two polling intervals and sent 5000 emails in about 30 seconds. To get absurd I increased the test to 10,000 emails and the Enterprise Edition cleared those out in less than 60 seconds. This means it took 4 polling intervals to process 10,000 emails which comes out to 2,500 every 15 seconds with 10 MailSpoolThreads. I wanted to verify this exactly so I decreased the polling interval from 15 seconds to 30 seconds. I wanted to fill the mail spool completely beforehand and see how many emails were processed on each polling interval. What I saw is that I'm not nearly at the limit of what the Enterprise Edition MailSpoolService can handle. By slowing down the polling interval my CFML script was able to put all 10,000 emails into the mail spool folder before the MailSpoolService started processing. Then it happened, all 10,000 emails were process in one single polling interval of less than 15 seconds time. I'm not sure were the limit is, but it's fairly clear that the Enterprise edition can send more emails than most of us will ever need. Even if you're running a bulk mail service.

Summary
My results are not scientific. However, I do believe they are closer to what real people will see on real servers based on my experience with hundreds of servers. It would be really nice if Adobe would respond with some real numbers so we could help clients decide if this feature is worth buying Enterprise Edition instead of Standard Edition. However, based on my testing, if sending emails is your high priority and the amount of emails is going to be over 50,000 emails per day then you might want to weigh the cost of an Enterprise license.

Note:
The reason I was testing on ColdFusion 11 is this is the version that several different clients have that are having issues with the MailSpoolService. I think I know that for one client they really are trying to send near or over 50,000 emails per day and this is why they thought there was an issue with the MailSpoolService.

Cryptocurrency Miners Hacking Servers

Are your free CPU cycles making others rich? There's a chance they are and it's at your expense. A recent article at Vice.com states that "At Least 1.65 Million Computers Are Mining Cryptocurrency for Hackers So Far This Year". If this is to be believed then it's possible a server you are running has been compromised and is actually mining cyrptocurrency for the hackers.

Cyrptocurrency is an anonymous, digital currency that is supposed to be untraceable. It's used on the internet to purchase more and more products and services. One of the most common forms of cryptocurrency is Bitcoin. This is from the Wikipedia entry on Bitcoin.

Bitcoin is a worldwide cryptocurrency and digital payment system called the first decentralized digital currency, since the system works without a central repository or single administrator. It was invented by an unknown programmer, or a group of programmers, under the name Satoshi Nakamoto and released as open-source software in 2009. The system is peer-to-peer, and transactions take place between users directly, without an intermediary. These transactions are verified by network nodes and recorded in a public distributed ledger called a blockchain. Besides being created as a reward for mining, bitcoin can be exchanged for other currencies, products, and services. As of February 2015, over 100,000 merchants and vendors accepted bitcoin as payment. Bitcoin can also be held as an investment. According to research produced by Cambridge University in 2017, there are 2.9 to 5.8 million unique users using a cryptocurrency wallet, most of them using bitcoin. ...

Bitcoin Mining is a record-keeping service that runs on peoples computers, servers, or specialized Mining Devices, that are setup by individuals to help process Bitcoin transactions. As a reward for doing this you are given newly created bitcoins and transaction fees. ie. You can make money by mining for Bitcoin.

This reward is enough that hackers have taken it to the next level and started hacking servers around the world so they can install mining software and use YOUR computers and servers to make money for themselves. Just this week it was discovered that some of Showtime's web servers were mining cryptocurrency. This isn't a new thing either. Back in 2014 Iowa State University servers were also hacked for the purpose on mining Bitcoins. These are not isolated occurrences. They are happening regularly. This practice is free to the hackers an costly to the owners of the servers. Here's why.

Case Study

CF Webtools has seen this type of hack in the real world. We recently had a company come to us seeking our services for both Server Administration and ColdFusion programming. Part of taking this new company on as a client we performed a security review on all of their servers. They also had existing issues that we needed to look at in particular. One of their web servers was rebooting multiple times per day at what seemed like "random" intervals.

Upon review we found the web server was always running at 100% CPU usage with no services claiming to be using that much CPU power. Certainly not ColdFusion or IIS. After completing additional research we decided to install a malware removal tool and scanned for malware. It didn't take long to find that indeed there was malware running on the server. What we found surprised us only because we had not seen this in action before. It was a cryptocurrency miner and it was so intensive that it would crash the server. All attempts to remove the malware failed. It would end up back on the server in a short period of time. The fact is this server was compromised. To resolve the issue we sent one of our decommissioned, but powerful servers, preinstalled with a clean OS to their data center. Then our Operations Manager went on the road to install the new server as well as a physical firewall. We essentially rearchitected their entire server setup. Meanwhile the malware removal tool did it's best to keep the malware at bay while I recreated their web server on the new server. It was a busy week (or more), but we were able to clean the code on the clients server and put that on the new server. We also had to research and rebuild all the dependancies from scratch. When it was all said and done we replaced the compromised server with the new one and put all their servers behind a Cisco ASA.

This case of Hacking for Bitcoins proved costly in the end to the company who's systems were compromised all while providing a free profit to the hacker(s).

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at cfwebtools.com.

ColdFusion Security Patches ColdFusion 11 Update 13 and ColdFusion 2016 Update 5

Adobe just released security updates for ColdFusion 11 and ColdFusion 2016. This is a critical security update and you should be updating your ColdFusion servers. The information below is from the CF Webtools operations group. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at cfwebtools.com. Meanwhile, this info below will help IT staff and DIY types get started.

With ColdFusion 11 Update 13 and ColdFusion 2016 Update 5 there are additional manual updates that are required to complete the security patch. The additional requirements are the same for both ColdFusion 11 and ColdFusion 2016 and the remaining information pertains to both versions. Both updates require that ColdFusion be running on Java version 1.8.0_121 or higher. For reference, ColdFusion 11 comes with Java version 1.8.0_25 and ColdFusion 2016 comes with Java version 1.8.0_72. The Java that needs to be installed is different from the "Windows User" Java client that may already be installed. The installer is available from Oracle. Once the new Java version installed, the jvm.config file for each ColdFusion instance needs to be updated to point to the new Java version installation path. If you're running the Enterprise version of ColdFusion, there's a likely chance there is more than one ColdFusion instance running.

Part of the instructions from Adobe says that if your ColdFusion server is installed as J2EE server then there is an addiction manual configuration that you ned to do. However, every installation of ColdFusion since the release of ColdFusion 10 is a J2EE or JEE installation. What Adobe really meant was that if you are using a third party JEE server and not the built-in Tomcat JEE server.

If your ColdFusion server is running on a third party JEE server such as WebLogic, Wildly, custom Apache Tomcat, etc (Not the built in Tomcat that comes with ColdFusion), then the following step needs to be completed.

Set the following JVM flag, "-Djdk.serialFilter=!org.mozilla.** ", in the respective startup file depending on the type of Application Server being used.

For example,

  • On Apache Tomcat Application Server, edit JAVA_OPTS in the 'Catalina.bat/sh' file
  • On WebLogic Application Server, edit JAVA_OPTIONS in the 'startWeblogic.cmd' file
  • On a WildFly/EAP Application Server, edit JAVA_OPTS in the 'standalone.conf' file

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them or if they are not familiar or knowledgeable with ColdFusion contact us at CF Webtools to patch your servers.

As always, if you need help migrating to the next version, scanning your ColdFusion server for security vectors or installing this patch and new Java version, contact your project or account manager directly, or send an email to support@cfwebtools.com. You can also simply respond to this email (or call 403-408-3733).

*Note: ColdFusion11 when it was first released came with a version of Java 1.7.0_nn. Adobe later re-released ColdFusion 11 with Java 1.8.0_25. If you have ColdFusion 11 still running on Java 1.7 I highly recommend that Java be upgraded to Java 1.8. Oracle is no longer supporting Java 1.7 and 1.7 is long past it's end of life. Even though the Adobe instructions for this current security update states that you can run Java 1.7.0_131, I highly recommend upgrading to Java 1.8.

Mary Jo Sminkey: Robust Error Handling Part 3 - Ajax

Part 3 in the super-guru's Mary Jo Sminkey's series on robust error handling. Enjoy!


So in my last post on error handling, I promised in this next one to cover logging of Ajax requests. As more and more of our site involves Ajax requests, this has become an important part of my error logging and debug work. If you want to know how to do this read on!

[More]

Building a Robust Error Handler Part 2

The Muse is fortunate to have a number of very talented and smart developers work for him. Mary Jo Sminkey has been with CF Webtools for several years now and we simply love having her around. She's a fantastic developer and a fantastic resource. You might catch her at cf.objective() where she will be speaking next week.

Meanwhile, you might remember part 1 of this series – Building a Robust Error Handler. Below is part 2 in that 3 part series. Enjoy!


Well it's taken a couple years to get around to it, but at long last here is part 2 of my error handling post! Of course, in that time I've continued to work on improvements to my error handler, so many changes that I'm going to need to break THIS post up into multiple parts as well. I'll try not to take too long to get the final part out to you!

So in part one we looked at things like using the error handler for both global errors as well as in cfcatch blocks, dumping all the available scopes while scrubbing them for any sensitive data, keeping track of already reported errors to prevent receiving tons of duplicate emails for the same error, etc.

In this post (part 2) we will expand the functionality of the error handler and talk about strategies for use throughout the application. Let's start with how to handle errors "in depth".

[More]

ColdFusion, SSL, SNI, SAN and Wildcards - Stuff You Need to Know

The Muse welcomes back his friend and colleague (and super genius guru) Wil Genovese with an timely post on SSL and Certificate types. If you have had your head in the ground (or perhaps you have been guest staring on "Naked and Afraid" or "Survivor") you may have missed the hubbub surrounding TLS, SSL and changes and support. There is a lot going on and it is more important than ever that you get your hands around the issue to keep your users safe. Wil has done Yeomen's work identifying the types of certs, the versions of ColdFusion and Java that support them, and work arounds and caveats for those of you who need them. You will likely want to bookmark this one. Take it away Wil.

[More]

ColdFusion and JVM Versions and SSLv3-TLS Security Magic

This is the second entry by Wil Genovese (Trunkful.com) 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:

[More]

Surviving Poodle - ColdFusion and SSL 3

There's been a great deal of buzz about poodle. Poodle is an SSL exploit capable of highjacking a session using a browser's ability to "negotiate downward" the level of SSL it uses. It's recent prolifieration has put some urgency into the efforts to force existing applications and platforms to deny the use of any standard of SSL less than version 3.0. Super guru Wil Genovese (Trunkful.com) recently did some troubleshooting on a ColdFusion server with an issue related to this necessary configuration step. Wil writes:

We ran into an issue when a company contacted us at CF Webtools because ColdFusion was suddenly no longer able to connect to their email providers mail servers. One day ColdFusion was sending emails to their clients just fine and the next day it was failing. As you know these issues are usually best resolved by asking "What changed?" As far as the client knew, nothing had changed - but we knew enough not to stop digging.

[More]

Side-by-side Configuration Error installing CF 11 on Win2008r2

One of my colleagues, Chris Tierney, was installing a pristine copy of ColdFusion 11 on a Windows 2008 server. He followed our standard protocol which is to install the server using the "built in" Web server, then create instances (we typically use multi-server mode) then use wsconfig.exe to connect the instances to IIS. It all went as planned until he tried to run wsconfig.exe (FYI - you must always run this as administrator). He got an error as follows:

java.io.IOException: Cannot run program "C:\Users\ADMINI~1.CFW\AppData\Local\Tem
p\2\\ExecuteAppCmd\ExecuteAppCmd.exe": CreateProcess error=14001, The applicatio
n has failed to start because its side-by-side configuration is incorrect.


Followed by an odd stack trace. After experimenting with permissions and googling he stumbled on Bug 3761543 in the ColdFusion bugbase. The issue is not very well documented. Apparently the MS C++ package installed on 08 is 32 bit. I'm not clear if we installed it or it shipped with 08, but remember, you need the MS C++ 64bit SP1 Redistributable. Here's the download link from Microsoft so you don't have to hunt it down.

The Fix

Microsoft Visual C++ 2008 SP1 Redistributable Package (x64)

One more time: This download fixes the "side-by-side configuration" when installing ColdFusion 11 on Windows 2008r2.

Business Referral - don't forget

A week ago, in my post, The Muse Has Cash... I started a new program to reward community members for leads. Thank you for all the input and for the many leads generated already. We really appreciate it and we'll make you proud! After a quarter or so I will report on the success of the program.

Meanwhile, a few have pointed out that the previous post is lengthy so I wanted to put up the "express checkout" version. It's simple, if you refer a lead to us (email cfleads@cfwebtools.com) that results in new business, we will pay back to you 8% of the gross revenue from that customer in the first 10 months of working with the customer. If the customer spends 10k with us, you make $800.00. Simple and easy. So hook the Muse up. We are looking for another record year!

Note: In the past the Muse has offered bonuses for referring developers to us. This program is for new business, not developers - although as always if you are looking for work send me your resume. We typically hire several times a year.

Running ColdFusion 10 in Distributed Mode

A recent discussion on CF-Talk had a member trying to find instructions for setting up ColdFusion in "Distributed mode" on a CF 11 server. If you have never heard of "distributed mode" you are not alone among CF developers. It's not a common setup in my experience. Here's a quick 101. Many processes and daemons on a given server communicate using the TCP stack. TCP provides a predictable, high capacity, mature protocol for piping requests and data in and out of server processes. In this case, IIS or Apache communicate with CF through the local loopback (localhost or 127.0.0.1) IP address and a port - usually 8012 (or 8013 or 8014) chosen at installation. Naturally you can alter the IP address to which you are connecting, changing it from the loopback to... well any IP that's listening on 8012. That means you can set up your ColdFusion servers separately from your web servers. After all it's just IP networking. Why would you do that? The Muse will let his guest handle that question.

Meanwhile, to preempt (or perhaps spur) discussion, the Muse will note that this process is similar to something called "Reverse proxy" which functions in much the same way. The difference being with CF distributed, IIS on the front end handles all the "http stuff" and passes the request to CF just like it was a local engine, whereas with reverse proxy the HTTP request is simply redirected to the alternate server. That means the alternate server needs to be a full webserver plus application server. While that increases the overhead a bit, it has some advantages - but that's a topic for a different post.

Back to our CF-Talk question, it quickly became apparent that not many folks actually knew how to accomplish this task on a CF 10 (or 11) server due to the underlying platform switch to Tomcat. After some back and forth Byron Mann chimed in with some very specific instructions on how to get this done. Byron is a lead engineer at HostMySite - which makes the Muse feel better about their ColdFusion support. :) Here's his tutorial.

[More]

IIS Vulnerability Steals Payment Information (By Wil Genovese - CFG)

Super guru Wil Genovese (Trunkful.com) is back to describe an IIS vulnerability that was inserted using a long-known (and patched) CF vulnerability. The Muse will make 2 points. First, if you are hit with this one call us! We will gladly put our shoulder to the wheel and help you dig out. Second, don't forget to patch your servers and keep up on the latest security news. No matter what your chosen platform you need to be vigilant and attentive. Take it away Wil.

First let me point out that the vulnerability that was found has a patch that has been available since January of 2013. So as the Muse said, patch your servers! I first read about this attack in a PC World article titled, PCWorld - Attackers exploited ColdFusion vulnerability to install Microsoft IIS malware. I spent hours reading all the linked websites and blog posts by the security researcher that discovered the IIS Malware (see this Trustwave post) trying in vain to learn the name of said DLL that gets installed, where it gets installed and how to detect the file(s). The few details I found were not completely useful. While I learned the behavior of the malware I never learned how to find the offending DLL or even the file name. I did discover that no existing anti-malware or anti-virus software would detect this rogue DLL. I repeated my futile search every few weeks to see if anything new was being reported.

Since knowing how to locate and expunge such things is part of my job I needed a way to find it, but how? I could search any of the servers at CF Webtools until the cows come home, but if none of them have been hit with this malware I will never find it. What I needed was a server that had been exploited to examine. Over the past year with the slightly larger than usual number of security holes discovered in ColdFusion we've had a few new clients come to us for help in patching and repairing servers. None of the IIS modules on those servers stood out to me as 'unusual', but I wasn't looking directly for this. Finally we had a company come to us for help with a breach.

[More]

Building a Robust Error Handler

If you have been around the ColdFusion world as long as the Muse you have heard of Mary Jo Sminkey. Mary Jo built a popular ColdFusion ecommerce platform called CFWebstore. She has vast experience in ColdFusion and a seemingly boundless fountain of energy. Her eclectic interests range from technology to baking to dog training. As far as CF Webtools and the Muse can tell, Mary Jo excels at everything she does. We frankly suspect she is actually twins or triplets pretending to be only one person :) The following article is by Mary Jo and details her approach to application specific error handling. She has a detailed and thorough knowledge of the topic. Using this approach she has been able to reduce the number of errors on a very high traffic E-commerce site to practically nil. In the first of 2 articles MJ (as we call her with great affection) details the structure and usage of the handler.

Building a Robust Error Handler (by Mary Jo Sminkey)

Let's face it, sometimes we put less effort into the error handler than into the rest of our code. We might put something in place that throws up a "user friendly" page, and maybe email a dump of the catch or error structure, but when the site goes live, and we are deluged with errors due to search bots, hack attempts and poorly coded pages we turn it off or send all those emails to a seldom-visited mailbox. Sometimes we implement error handling as cftry/cfcatch blocks that do little more than preventing errors from being thrown, instead of helping us track down the issue.

I look at the error handler as a way to help make a site as bug-free as possible. By having it email me as much information as possible about errors, I troubleshoot, fix and patch, and get to a point where errors are the exception rather than the rule. In this article, we'll look at building a single-page, comprehensive error handler. In a future article, we'll look at integrating that error handler with the open source bug tracker BugLogHQ. Before we begin with our error handler let's talk about our error handling strategy.

[More]

More Entries




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