ColdFusion Muse

ColdFusion Debugging on Production

Today's short note is brought to you by "Don't Do That On Production!" At CF Webtools often times we get called in to help troubleshoot servers that are failing to perform well. We often hear the same sort of symptoms that goes like this. The server has been running fine for months then suddenly for no reason it's slow, CPU usage is high, and it hangs or crashes multiple times per day. This always prompts us to ask the same question. "What was changed just before these symptoms started?" And the answer is usually "Nothing was changed (as far as they knew)". In all reality the person we're talking to may not the be only person with access to make changes to the server. Or they may not in fact have access at all and they are relying on information provided to them by an IT team member. We take notes, assume nothing, and question everything (on the server).

We had this scenario play out a few times in the past few weeks with three servers from three different companies. The reason I'm writing this note is the same problem occurred on each server. The short answer is someone enabled ColdFusion Debugging on the production server. ColdFusion is a very powerful rapid development platform, but it has a few gotchas if you are not careful. Such as enabling debugging on a production server. Debugging output provides a massive amount of information and for obvious security reasons we never want this enabled on a production server. Yes, I know you can restrict debugging output to a certain IP address, but that does not prevent the debugging output from being generated. It's just not displayed. The generation of debugging output takes more CPU power and at times more JVM memory. On a low load web application you may not notice a difference. However, on a high load, high traffic production web application the extra resources needed to generate the debugging output may in fact cause all those symptoms described above.

In each of the cases we saw these past few weeks, we were reviewing the servers settings, looking at the results of Fusion Reactor, and reviewing ColdFusion settings. On the first server we almost missed the fact that debugging was enabled. By the time we were troubleshooting the third server with similar symptoms we were checking to see if debugging was enabled before we did anything else. Disabling debugging resolved the bulk of the performance issues. We then used this time to review each server and offered additional performance tuning recommendations based on each servers resources and application needs.

This falls into the category of "Don't Do That On Production!" Please leave debugging to your development and staging servers.

CF Webtools is here to fill your needs and solve your problems. If you have a perplexing issue with ColdFusion servers, code, connections, or 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 @ cfwebtools.com.

USPS Shipping API Ending TLS 1.1 and TLS 1.0 Support, is your ColdFusion Server Ready?

At CF Webtools we recently went through a round of server upgrades to handle the Authorize.net ending support for older TLS versions. Now USPS, United State Postal Service, is doing the same thing with their Shipping APIs. This is going to be happening for all API's and most likely all this year as PCI requirements for ending support for TLS 1.1 and older at the end of June 2018. This is according to the PCI Security Standards Council.

USPS will be turning off support for TLS 1.1 and older for testing. In advance of the changes to production, TLS version 1.0 and 1.1 support will be discontinued in the lower Web Tools environments and available for testing on 5/22/18: https://stg-secure.shippingapis.com/shippingapi.dll): 06/11/18.

This message explains some security improvements planned for our services. Effective 06/22/18, Web Tools will discontinue support of Transport Layer Security (TLS) version 1.0 and 1.1 for securing connections to our HTTPS APIs through the following URL: https://stg-secure.shippingapis.com/shippingapi.dll. This includes, but is not limited to, all shipping label and package pickup APIs. After this change, integrations leveraging TLS version 1.0 and 1.1 will fail when attempting to access the APIs.

You are receiving this message because the Web Tools UserID associated with your email address has made HTTPS requests over the past year. It is possible that no changes are necessary to retain Web Tools services and benefit from the improvements. Please review the entire message carefully and share with your web developer, software vendor, or IT service provider to determine if your use of the Web Tools APIs will be affected. If you have already updated your security certificates please disregard this message. If you are not sure if any changes are necessary, please ask your IT service provider.

In advance of the changes to production, TLS version 1.0 and 1.1 support will be discontinued in the lower Web Tools environments and available for testing on 5/22/18: https://stg-secure.shippingapis.com/shippingapi.dll): 06/11/18.

Further background: Security research published in recent years demonstrated that TLS version 1.0 and 1.1 contained weaknesses that limited its ability to protect and secure communications. These weaknesses have been addressed in the TLS 1.2 version. Major browser software vendors have been supporting TLS 1.2 for some time. Consistent with our priority to protect USPS Web Tools customers, Web Tools will only support versions of the more modern TLS 1.2 as of the effective date noted above.

Contact us at WebTools@usps.gov with any questions or concerns.

This means that if you are using older methods to make calls to USPS that are not capable of making TLS 1.2 connections then you will NOT be able to process Shipping API 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 Shipping API transactions with USPS then this advisory applies to your server.

Mitigation Getting compliant depends on age of your server operating system. There are three main ways to get your server to handle TLS 1.2.

  1. If you're running on Windows Server 2008 Standard (not R2) or older then the only solution is to migrate to a newer server. This can be challenging and time consuming. It's best to start planning now if a plan isn't already in place and being acted upon.
  2. If your server is running ColdFusion 10 and newer on Windows 2008 or newer then the solution is most likely very simple. In most cases you'll need to install the ColdFusion patches and upgrade to Java 1.8.0_nn.
  3. There is a solution for the in between systems running ColdFusion 9 and older on Windows 2008 R2. This does require using a third party extension to ColdFusion and some refactoring of your code to call the API.
  4. There are sure to be outlier cases that will require either migration or patching depending on the exact combination of operating system, ColdFusion version and Java version.

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 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.

NEWSFLASH! Adobe Released the New ColdFusion 2018 Public Beta!

Adobe has announced the Public Beta of Adobe ColdFusion 2018 is now available. This release brings an all new Performance Monitoring Toolset that is available with both the Standard and Enterprise versions (So I've been told). There's plenty of language improvements and updates and a new Public Beta of ColdFusion Builder 2018. Hurry up while supplies last!

There a large number of changes including an all new ColdFusion Administrator. Here's a partial list of new things according to Adobe:

  1. ColdFusion (2018 release) has a new User Interface. The new interface is based on a tiled interface. We have also enriched the search experience on the Administrator portal.
  2. We have removed Server Monitor. We have introduced a tool called Performance Monitoring Toolset, which is more intuitive, includes more features, and provides better visibility of your application's performance.
  3. We have made significant improvements to the core language features. Here is a brief list of the changes:
    1. Introduced NULL support
    2. Introduced closures in tags
    3. Introduced Asynchronous programming using Future
    4. Enhanced Object-Oriented Programming with the following:
      1. Abstract components and methods
      2. Final component, method, and variable
      3. Default functions in interfaces
      4. Covariance
    5. Semi-colons are now optional in a cfscript code
    6. Introduced named parameters in functions
    7. Introduced slicing in arrays
    8. New operator support using name-spaces for java, webservices, dotnet com, corba, and cfc
    9. Introduced support for typed arrays
    10. Introduced string literals and support for numeric member functions
    11. Introduced negative indices support for arrays
    12. New functions- ArrayFirst, Arraylast, QueryDeleteColumn, and QueryDeleteRow
  4. Enhanced CLI and introduced REPL.
  5. Introduced REST Playground application for testing your REST APIs.
  6. Added support for REST PATCH verb.
  7. Filter fields from JSON request.
  8. Enhance performance through Caching with the newly added engines:
    1. Memcached
    2. JCS
    3. Redis
    4. Using a custom cache plugin
  9. New Admin APIs to support the caching engines
  10. Hibernate upgraded to ver 5.2
  11. New configuration settings in wsconfig tool
  12. Updates to ColdFusion Builder.

This is a huge update! Get it while it's hot!

ColdFusion Security updates for ColdFusion 2016 and ColdFusion 11

Adobe released important security updates and big fixes today, update 6 and update 14 for ColdFusion 2016 and ColdFusion 11 respectively.

These updates resolve an important insecure library loading vulnerability (CVE-2018-4938), an important cross-site scripting vulnerability that could lead to code injection (CVE-2018-4940) and an important cross-site scripting vulnerability that could lead to information disclosure (CVE-2018-4941). These updates also include a mitigation for a critical unsafe Java deserialization vulnerability (CVE-2018-4939) and a mitigation for a critical unsafe XML parsing vulnerability (CVE-2018-4942).
There is a bug of great importance to many that has finally been fixed. I've blogged about this before and I was able to create a work around to resolve this issue until it was fixed by Adobe. The SFTP/FTPS bug would not allow connections to secure FTP servers that utilized newer SSL protocols. When using CFFTP to connect to some S-FTP server, during connection, you can see an error message. This has been a growing issue as more and more companies replace plain text FTP servers with SFTP or FTPS servers that utilize stronger protocols.

For ColdFusion 2016 this update upgrades Tomcat to version 8.5.28 and OpenSSL to version 1.0.2n.

For ColdFusion 11 this update upgrades Tomcat to version 7.0.85 and OpenSSL to version 1.0.2n.

The security updates referenced in the above Tech Notes require JDK 8u121 or higher (for ColdFusion 2016) and JDK 7u131 or JDK 8u121 (for ColdFusion 11).

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. 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.

*Note: ColdFusion 11 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. Personally I will not install Java 1.7 on a clients servers and sign off on it being 'secure'.

ColdFusion SFTP and FTPS Secure Connection Failure

I have seen a lot more people asking questions about making SFTP or FTPS secure connections from ColdFusion using the <CFFTP> tag. They are trying to figure out why they cannot make a connection. Often the error is "Algorithm negotiation fail" or "Connection Error". People are posting their questions on many support forums including Adobes forums and their new ColdFusion Community Portal. This is a problem people are experiencing in ColdFusion 10 and ColdFusion 11.

In the last few years we've seen a huge shift in SSL/TLS security including the removal of older less secure protocols and forcing secure connections to use the newer stronger protocols with stronger TLS certificates and stronger encryption cyphers. As such older systems need to be upgraded to handle the newer security protocols. More recently plain old unsecure FTP portals have been the focus of change to SFTP or FTPS.

At CF Webtools we've run into this same problem several times with multiple clients. It was so much of a problem that I needed to spend some dedicated time to see how we could resolve this issue.

The first thing I discovered is that this issue is a known "bug" that has been reported to Adobe. It's been a long known issue and somehow the fix which is in ColdFusion 2016 has not been included in an update for earlier ColdFusion versions. However, Adobe has affirmed to me that this fix is scheduled for an upcoming update.

Because it was fixed in ColdFusion 2016 I was able to inspect the included jar files to see if the one that handles CFFTP or secure communications was newer than the one(s) in ColdFusion 11. What I found is that jsch-0.1.44m.jar had been replaced by jsch-0.1.52m.jar. The JSCH jar library is the library that handles Java Secure Channel communications. "JSch allows you to connect to an sshd server and use port forwarding, X11 forwarding, file transfer, etc., and you can integrate its functionality into your own Java programs."

After seeing this was upgraded I had an ah-ha moment and figured it was worth a try to copy this newer version into my ColdFusion 11 test server and see what happened. The new version is in ./ColdFusion2016/cfusion/lib folder. You can download the free ColdFusion 2016 Developer Edition and install it anywhere so you can get access to the updated jar file. Once you have the new jar file copy it into ColdFusion 11. The proper way to do this is to remove or rename the old jar file version in your ColdFusion11/cfusion (or instance name)/lib folder then copy the new jar file version into the same folder. Then start or restart ColdFusion 11. That's it. You're done. The bug is fixed and you're good to go with SFTP or FTPS using <CFFTP> in ColdFusion 11.

This is not an approved fix from Adobe. I do not know if there is some unknown issue that could be created by doing this. However, I do know that everyone I've talked to that has tried this has had their secure FTP issues resolved. Additionally I have not tried this 'fix' in ColdFusion 10. However, if you are running into this issue with ColdFusion 10 it's worth the minimal effort to give it a try.

If you need someone to make this change on your ColdFusion server then contact us, we can help. CF Webtools is here to fill your needs and solve your problems. If you have a perplexing issue with ColdFusion servers, code, connections, or 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 @ cfwebtools.com.

Connect ColdFusion JDBC to Sybase SQL Anywhere 16

This is something that might not come up often, but every once in a while we have to connect to a Sybase database. This is a built in feature in the Enterprise version of ColdFusion. However, if you have the Standard version of ColdFusion you have to manually add the JDBC jar file and build the connection string by hand. This is easy to do once you have the correct information and correct format of the connection string. Finding that correct information was nearly impossible and required a lot of trial and error.

Here's the case we had to resolve at CF Webtools. One of our clients has been using ColdFusion and Sybase for ages. For the record this is Sybase SQL Anywhere 16. For those that are not aware SAP owns Sybase thus the official name is SAP SQL Anywhere 16. For the longest time they were using ODBC connectors and older versions of ColdFusion on older Windows servers. More recently they have upgraded to ColdFusion 11 on newer Windows servers and were still trying to make the connections to Sybase via ODBC. This is a large multi-tenant operation in which there are hundreds of databases on the Sybase servers. Yes, plural servers. There are two servers that are replicated and handle failover. This means the ColdFusion Datasource connection also needs to handle failover. With ODBC failover is handled by Microsoft ODBC settings. With JDBC we had to setup failover in the JDBC connection string.

[More]

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.

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.

UPDATE: This fix will not work for Windows 2003 Server as there is no support from Microsoft for TLS 1.1 or 1.2 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]

More Entries




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