Old News Anew: Fixing Zen Cart for SSL v3 Vulnerability

PayPal was supposed to have made the change on December 3, the date it announced as the target for no longer accepting secure connections from sites using SSL v3 instead of TLS. As I manage a Zen Cart site which uses PayPal’s express checkout as it’s only payment option, I checked with the server’s technical support staff to make sure we were covered. Yup. We got you set up with that, they said. I was good to go.

When December 3 came and went with the site continuing to take orders, I figured I had weathered the storm quite handily, although this seemed a little too easy to me.

Then came Monday night.

While I was away from home and office, sitting at a borrowed computer, I received a series of emails from PayPal, notifying me that a customer was making repeated unsuccessful attempts to place an order — unsuccessful because PayPal was refusing the handshake from the server. I easily recreated the problem by logging on to the site using a dummy customer account and attempting to make a purchase. At the point where the order was sent to PayPal, the process failed with a red letter warning saying something like “(35) error:14094410:SSL routines:func(148):reason(1040).” Not cool.

A Google turned up an article on Zen Cart’s site, which had been posted in October in anticipation of this change, outlining what needs to be done to keep a Zen Cart site operational. The best thing to do is upgrade to the latest and greatest Zen Cart, version 1.5.4, which is good to go. However, the nature of Zen Cart (or its cousin osCommerce) means many sites are heavily modified and in most cases can’t be quickly upgraded to a new version without losing all modifications.

The trouble I was experiencing is due to the fact that Zen Cart forces the use of SSL v3 as a work around for an older security problem. When SSL v2 became vulnerable many years back, Zen Cart’s answer was to force v3 at the handshake to block any v2 attempt. That worked for a long time, but now that v3 is the problem — not so good.

Fixing the problem requires finding and making an edit to a file in a payment module. The payment module or modules will depend on the payment methods accepted by the site and the edit is the simple commenting out of the line forcing SSL v3. This can be done either by using the file manager included in a cPanel installation or by use of an FTP client. I chose the later.

In my case, I needed to edit two files.

I fired up the ol’ FTP client, navigated to the first file and downloaded it to my local machine. I then opened it in a text editor (not a word processor), in my case Bluefish. After scrolling down to the proper line, I looked for a string reading “curl_setopt($ch, CURLOPT_SSLVERSION, 3);” or (in the case of paypal_curl.php) “CURLOPT_SSLVERSION => 3,” and commented the line out by use of two slashes to read, “// curl_setopt($ch, CURLOPT_SSLVERSION, 3);” or ” // CURLOPT_SSLVERSION => 3,” and saved the file.

Before uploading the edited file to the server, I took the precaution of changing the name of the unedited file it’d be replacing to oldpaypal_curl.php to keep it from being overwritten. That way, if something about my edit, as simple as it was, broke the file, I could easily put things back by restoring the original unedited file. After that, I simply uploaded the new file and repeated the entire procedure with the second file.

After that, I tested the fix by logging in as a customer and attempting to make a purchase. Voila! It worked. When I reached the payment stage, PayPal was ready, willing and able to take my payment information.

Most Zen Cart operators have probably already made their sites ready and this won’t be a problem. However, just in case…

Christine Hall

Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux

FOSSForce.com