Jump to content

UPS Contract Module


jka

Recommended Posts

The UPS module (Contract? Other than the standard module?) uses CubeCart's "Request" functions. Therefore, there will be the Request and their Response in admin, Request Log.

CubeCart does not ship with any TLS component. It relies on PHP to supply it, and/or the hosting server to make comms with TLS.

In CubeCart admin, PHP Info, the top-most chart will have a row for "Registered Stream Socket Transports". See if 'tls' is listed here.

Then, in the CURL table, see if TLS is mentioned in any way. Then, in the OPENSSL table, see if PHP has access to version 1.0.2m.

Edited by bsmither
Link to comment
Share on other sites

Hello BSmither,

Happy New Year !

I see the following .. 

Registered Stream Socket Transports

tcp, udp, unix, udg, ssl, sslv3, sslv2, tls, tlsv1.0, tlsv1.1, tlsv1.2

I wonder if the module is using TLS to make the calls explicitly?? We use UPS Contract. For now due to this issue, we are dead in the water since the cart does not let checkout without proper shipping rates.

 

Here is the response from UPS ...

UPS has upgraded the communication security protocols for all web-based applications, including UPS Developer Kit, UPS.com, CampusShip, and etcetera. Please contact your company's IT department or development team to ensure that any security protocols currently used meet the TLS 1.2 requirement. If Java is enabled, it must be version 1.7 or higher to use TLS 1.2.

As of December 31, 2017, all API URLs, including old API URLs starting with www.ups.com/ups.app/xml/ or https://www.ups.com/webservices/, have been transitioned over to ignore any traffic using TLS 1.0. 

If you are using any API URLs starting with www.ups.com/ups.app/xml/ or https://www.ups.com/webservices/, please update them to the currently supported URLs noted in their respective Developer Guides. They start with https://www.onlinetools.com.

Please note that our CIE Environment will only accept TLS 1.2 requests since it was transitioned over back in February 2017. 
 

Link to comment
Share on other sites

I added more info to my response above. Please refresh this page.

Are you referring to: https://www.cubecart.com/extensions/shipping-methods/ups-advanced-shipping-module

The gateway class file for this module is probably encoded, so there would be no easy way to check if it is setting/overriding the comms method for CURL to use.

Link to comment
Share on other sites

Just checked shipping.class.php and admin, its all encoded gibberish. Will have to wait for the Noodleman to respond since the url change at UPS seems to causing this issue. 

I am surprised that others have not reported this yet.

Link to comment
Share on other sites

No doubt they will.

We can try to force the Request class to use SSL/TLS.

In /classes/request.class.php:

Near line 237, in the function send(), find:

if($this->_request_hash === null) {
	$this->setData();
} 

On the blank line after that, add:

$this->setSSL();

Save.

I do not know if, by setting SSL, which just changes the port (443) and protocol (https), that TLS will somehow enter into the handshake with the remote server.

Test. Watch for inadvertent problems caused by forcing all CURL comms (via using the Request class) to secure when not actually planned for it.

Edited by bsmither
Link to comment
Share on other sites

We can also implement a work-around regarding the URLs. In the Request Class, we can add a statement that tests for the existing (but obsolete) UPS URL and switch it to use the new URL.

But we will need to determine what that existing URL is by looking at the Request Log (if the module uses CubeCart's Request functions).

Link to comment
Share on other sites

So, the UPS_contract module stores it error logs in the module window. There is nothing in the request.log for UPS Contract. However I added the standard UPS module and noticed in the request.log that it calls http://ups.com/xxxxx

Maybe we can try temporarily patching up http://ups to be forced as https://ups until the developer takes a look and patches it up.

Link to comment
Share on other sites

Having made the change to the request.class.php file, that should have made the request use https.

I wonder if the UPS_Contract module does not use the Request class. We can force the Request class to log, even if the calling function sets it to not log.

Near line 156, find: if (!$this->_log) return false;

Change to: //if (!$this->_log) return false;

Link to comment
Share on other sites

We just went ahead and made only TLSv1.2 as the only available TLS on the server. This way all transactions from the server will be 100% TLS 1.2. However the issue still remains. Hopefully Noodleman will have the fix tomorrow. 

Link to comment
Share on other sites

"We"? Do you have complete control of the server? If so, then maybe something like Wireshark could be used to observe the initial DNS resolution call with the UPS URL. (The server may have its own DNS cache at 127.0.0.1, so this may be non-starter.) But once the IP address is known, encryption - if employed - stops us at that point.

Link to comment
Share on other sites

We have our own Plesk VPS server for Production and a separate one for QA. I have added enough info for Noodleman to t-shoot the module. It appears that UPS were moving away from their legacy tools since 2017 and they decided to pull the plug Jan 1. As of now they are throttling their legacy API calls and the reason for the intermittency. 

https://www.ups.com/us/en/help-center/technology-support/data-security.page

Link to comment
Share on other sites

The issue is caused by the web server. the module makes a call to UPS using the cURL library and that will be negotiating using TLS1.0. It's unrelated to CubeCart cofiguration since it's the initialize of the request that negotiates the protocol. 

Review your PHP/cURL configuration first, if no joy I can send an updated module with a line of code that should force TLS 1.2 if your cURL libraries support it. You should ensure your cURL library is on the latest version for your PHP release. I have seen an out of date cURL library cause this kind of issue in the past. 

 

 

 

Link to comment
Share on other sites

6 hours ago, jka said:

We went ahead and did a cURL library update to the latest version 7.57 and its fixed now. Everything is back up and running. Thanks.

The joys of running your own server / VPS instance !  You need to look at what cyphers your server supports - you certainly shouldnt be allowing SSLv2, SSLv3 and even TLS1.0 can probably be removed especially with TLS1.3 now around

Link to comment
Share on other sites

Thanks. The server is PCI-DSS compliant with only TLS1.2 permitted by the webserver as well as A+ result from SSLlabs test. The cURL libraries are not part of Plesk and hence it wasnt on the radar whenever the server is automatically updated. 

Link to comment
Share on other sites

Today I learned (TIL) that PHP's CURL extension has it's own embedded libraries of OpenSSL. That means PHP's CURL extension can operate differently than PHP's OpenSSL extension, depending on the respective versions of each. (It seems CURL can be 'built' with any one of a number of security cipher libraries.)

Link to comment
Share on other sites

Absolutely. I also went ahead and updated to the latest OpenSSL version too. We all assumed that updating php takes care of cURL but obviously not the case. In fact we had to download the cURL libraries independently of Plesk. The normal Yum stuff didnt work.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...