jka Posted January 5, 2018 Share Posted January 5, 2018 Folks, Anyone having issues since Jan 1 with the UPS Contract module? It doesnt seem to be fetching any rates, I get the big red error box which states no suitable shipping methods found. Quote Link to comment Share on other sites More sharing options...
jka Posted January 5, 2018 Author Share Posted January 5, 2018 Actually its very intermittent and shows one rate at a time or shows error everytime we reload the screen. This prevents the customer from being able to checkout. Quote Link to comment Share on other sites More sharing options...
jka Posted January 5, 2018 Author Share Posted January 5, 2018 Just called UPS and they said as of today if the website is not using TLS 1.1 or 1.2 they are rejecting 75% of legacy tools. Any pointers on this TLS 1.1 or 1.2 ??? Quote Link to comment Share on other sites More sharing options...
bsmither Posted January 5, 2018 Share Posted January 5, 2018 (edited) 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 January 5, 2018 by bsmither Quote Link to comment Share on other sites More sharing options...
jka Posted January 5, 2018 Author Share Posted January 5, 2018 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. Quote Link to comment Share on other sites More sharing options...
bsmither Posted January 5, 2018 Share Posted January 5, 2018 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. Quote Link to comment Share on other sites More sharing options...
jka Posted January 5, 2018 Author Share Posted January 5, 2018 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. Quote Link to comment Share on other sites More sharing options...
bsmither Posted January 5, 2018 Share Posted January 5, 2018 (edited) 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 January 5, 2018 by bsmither Quote Link to comment Share on other sites More sharing options...
jka Posted January 5, 2018 Author Share Posted January 5, 2018 Unfortunately that wasn't the issue. Its probably something to do with the url change. Quote Link to comment Share on other sites More sharing options...
bsmither Posted January 5, 2018 Share Posted January 5, 2018 Then that message should be in the Request Log (see previous reply). Quote Link to comment Share on other sites More sharing options...
bsmither Posted January 5, 2018 Share Posted January 5, 2018 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). Quote Link to comment Share on other sites More sharing options...
jka Posted January 5, 2018 Author Share Posted January 5, 2018 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. Quote Link to comment Share on other sites More sharing options...
bsmither Posted January 5, 2018 Share Posted January 5, 2018 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; Quote Link to comment Share on other sites More sharing options...
jka Posted January 5, 2018 Author Share Posted January 5, 2018 You were spot on, it seems that module does not use the Request.class. There is still nothing in the log after the change. Quote Link to comment Share on other sites More sharing options...
jka Posted January 6, 2018 Author Share Posted January 6, 2018 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. Quote Link to comment Share on other sites More sharing options...
bsmither Posted January 6, 2018 Share Posted January 6, 2018 "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. Quote Link to comment Share on other sites More sharing options...
jka Posted January 6, 2018 Author Share Posted January 6, 2018 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 Quote Link to comment Share on other sites More sharing options...
Noodleman Posted January 8, 2018 Share Posted January 8, 2018 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. Quote Link to comment Share on other sites More sharing options...
jka Posted January 8, 2018 Author Share Posted January 8, 2018 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. Quote Link to comment Share on other sites More sharing options...
havenswift-hosting Posted January 8, 2018 Share Posted January 8, 2018 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 Quote Link to comment Share on other sites More sharing options...
jka Posted January 8, 2018 Author Share Posted January 8, 2018 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. Quote Link to comment Share on other sites More sharing options...
bsmither Posted January 8, 2018 Share Posted January 8, 2018 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.) Quote Link to comment Share on other sites More sharing options...
jka Posted January 9, 2018 Author Share Posted January 9, 2018 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.