topic Re: TLS 1.2 Sandbox vs Production in Integration and Testing

TLS 1.2 Sandbox vs Production

kvsunil — Thu, 08 Feb 2018 20:37:39 GMT

We have tested our sandbox instance after explicitly enabling JDK 1.7 to support TLS 1.2 . This worked fine without issues. So we have applied the same for production server. While checking on our production during the temporary TLS 1.2 enablement on Authorize.net production, it is running into the following issue : “javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure”

Sandbox Url : https://test.authorize.net/gateway/transact.dll

Production Url : https://secure.authorize.net/gateway/transact.dll

It seems like there is something different between Authorize.net Sandbox vs Production. Please advise. Thank you!

Re: TLS 1.2 Sandbox vs Production

jantzenw — Fri, 09 Feb 2018 16:05:28 GMT

We ran into a similar problem. Here is a partial list of ciphers that work on beta but did not work during the live disablement testing yesterday:

ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:KRB5-IDEA-CBC-SHA:KRB5-IDEA-CBC-MD5:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:KRB5-RC4-SHA:KRB5-RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:KRB5-DES-CBC-SHA:KRB5-DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-RC4-MD5:EXP-KRB5-RC4-SHA:EXP-KRB5-RC4-MD5

It seems like beta is accepting DEFAULT:!TLSv1.0 but live was allowing only DEFAULT:!TLSv1.0:!SSLv3

Re: TLS 1.2 Sandbox vs Production

kvsunil — Tue, 13 Feb 2018 01:11:25 GMT

Could someone please advise what actually needs to be setup for JDK 1.7? The settings applied on Sandbox instance works fine as explained above. Whereas the same failed on production during the temporary disablement on February 8th. Please advise.

Thanks in advance!

Re: TLS 1.2 Sandbox vs Production

weyco44 — Thu, 15 Feb 2018 20:44:19 GMT

We ran into the same issue. We even tested the sandbox during the disablement period, just to verify that we had things running on the sandbox environment.
correctly

We were led to believe that the sandbox would mimic the production environment, following the permanent disablement of the TLS 1.0/1.1.

Is there anyone that has found the differences between the sanbox and the temporarily disabled production site?

We have a ticket open, have done online chats, and had phone calls with no luck so far. Any help would be greatly appreciated.

Re: TLS 1.2 Sandbox vs Production

kvsunil — Tue, 20 Feb 2018 15:55:44 GMT

It seems like mostly this issue is because of JDK 1.7 JCE Unlimited Strength was not enabled.

Enabled JCE Unlimited Strength for JDK 1.7 on dev instance and tested against Authorize.net sandbox. It worked as usual even without this.

Enabled the same (JCE Unlimited Strength) on production and waiting Fingers Crossed. Need to check how it goes on Feb 28th! If that works Authorize.net sandbox and production are not on same security base line.

Ref: https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https

"Example of diagnosing a problem" section.

"In the case above, the failure occurred during the handshake. The most likely cause for that is algorithm support. The JDK provides a separate package called JCE Unlimited Strength, designed to add stronger algorithm support than what’s available by default."

"Adding stronger algorithms: JCE Unlimited Strength" section:

In a high security environment, one way of strengthening algorithms in the JDK is through the JCE Unlimited Strength policy files. In this particular case, replacing those policy files within JDK 7 allows it to use the stronger variants of existing algorithms and connect successfully.

Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7 Download :

http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

Thanks!

Re: TLS 1.2 Sandbox vs Production

kornysnaps — Thu, 22 Feb 2018 16:10:12 GMT

Authorizenet's production and snadobx envirnments are clearly different from each other.

We use the same server to test both and the sandbox works but production does not. On Jan 30 we tested successfully against the sandbox, then two minutes later failed against production using Akamai. On Feb 8th we tried the same thing with the non-Akamai gateway and had the same results.

Since Feb 8th I have been trying to get help from Authorizenet. Yesterday the first reply came saying we were using TLS 1.2 on 1/30 and 2/8. HELOOOOO! We know that. They did not go any futher to look into production versus sandbox.

We have used this service for the past 15 yesrs and have never had good support. It is like they are in another universe.

We now have less than 5 days before they turn it off. Obviously they do not care. It is probably more like they are not capable.

Re: TLS 1.2 Sandbox vs Production

raviparmarce88 — Fri, 23 Feb 2018 07:43:26 GMT

We have forcefully override tls1.2 version in our application and it is working fine in sandbox without any issue.

We hope it should also work in production.

Re: TLS 1.2 Sandbox vs Production

Anurag — Sat, 24 Feb 2018 08:23:19 GMT

Hi All ,

We have updated our FAQs for the cipher support

https://support.authorize.net/authkb/index?page=content&id=A1623&actp=search&viewlocale=en_US&searchid=1519401586050#Support

For cipher support ECDHE and AESGCM are preferred, SHA-1 ciphers will be not be supported. For a full list/report SSL Labs report can be run to see and verify TLS version and ciphers supported. Please see below for a matrix of reports available, by API endpoint and environment.

	Production	Sandbox
Transact, Legacy (Non-Akamai)	https://www.ssllabs.com/ssltest/analyze.html?d=secure.authorize.net	*Not Applicable*
Transact, Akamai	https://www.ssllabs.com/ssltest/analyze.html?d=secure2.authorize.net	https://www.ssllabs.com/ssltest/analyze.html?d=test.authorize.net
ANet API, Legacy (Non-Akamai)	https://www.ssllabs.com/ssltest/analyze.html?d=api.authorize.net	*Not Applicable*
ANet API, Akamai	https://www.ssllabs.com/ssltest/analyze.html?d=api2.authorize.net	https://www.ssllabs.com/ssltest/analyze.html?d=apitest.authorize.net

Re: TLS 1.2 Sandbox vs Production

raviparmarce88 — Mon, 26 Feb 2018 09:24:26 GMT

Could you please let me know how can we ensure that current production version would work fine after this tls disablement ?

Current application with Sandbox is working fine.

Re: TLS 1.2 Sandbox vs Production

weyco44 — Mon, 26 Feb 2018 16:01:48 GMT

Has the sandbox been updated to reflect this? Was this how the production version was set up during the Feb 8th test? Was there a mistake made while doing the test run that caused all of these errors for people?

Is there any way to verify that we will not lose connection once the Feb. 28th deadline comes?

Why did it take this long to give any sort of response?

Re: TLS 1.2 Sandbox vs Production

zigerati — Wed, 28 Feb 2018 16:09:34 GMT

Our Sandbox tests worked and now our system is not working after the rollout. No good direction from Authorize.net. We're confirmed with our Datacenter, Rackspace, that the server configurations are correct. Basically we're getting a "Status call failed" related to our recurring billing and connection errors for standard purchases. We've removed all weak cyphers and the servers are confirmed TLS 1.2 only. We're desperate. Any ideas?

Re: TLS 1.2 Sandbox vs Production

kvsunil — Wed, 28 Feb 2018 16:46:37 GMT

As posted in one of my replies above, even after configuring Unlimited JCE support JDK 1.7 didn't fix the issue!!!

Surprisingly, "The same solutions" are working with sandbox.

Dear Authorize.net Support, Your Sandbox and Production are supposed to be in same configurations. But it is not yet. What else needs to be done? Something missing.

Re: TLS 1.2 Sandbox vs Production

kvsunil — Wed, 28 Feb 2018 18:36:22 GMT

Since no use testing against Authorize.net Sandbox with JDK 1.7 went ahead and tested against Authorize.net production with JDK 1.8. That solved the issue!!!

Now need to setup and test with dev servers and then to production.

Authorize.net, any information from your end? Authorize.net Sandbox works with JDK 1.7 but not Production?!? What is the production readiness?

Re: TLS 1.2 Sandbox vs Production

kornysnaps — Thu, 01 Mar 2018 01:34:26 GMT

We had the same issues with the sandbox vs production and received no help from this service. Fortunately we have been planning to move away from authorizenet and were force to speed this up in the past two weeks. We now have 99% of our clients using another gateway. The 1% that remain do now seem to work in production. My only guess is because we upgraded from java 1.7 to java 1.8 this past Saturday.

It is a comfort to know that we have cleared this hurdle, but the bad taste lingers. The 1% will remain with authorize because they are lower volume, but we have no intention of coming back with the 99% that have been moved away.

I probably lost 10 years of my life because of this ordeal.

Re: TLS 1.2 Sandbox vs Production

weyco44 — Thu, 01 Mar 2018 15:08:24 GMT

We had a contingency plan to jump ship, similar to what kornysnaps described. This shouldn't be neccessary, but the fear of coming to work and having all eCommerce grind to a halt will put some gray hairs on a head rather quick. It was all ready- could have been done at 2:01AM and we would be a lost customer. There are other payment provider options out there. Authorize.net isn't the only game in town.

To anyone still struggling a suggestion would be to reorder cipher suites. If authorize.net wants to use SHA2 or SHA3 consider putting them at the top of the order. You may not want to leave out any of pre-existing ciphers as, if you are like us, authorize.net isn't the only gateway to talk to.

Re: TLS 1.2 Sandbox vs Production

LoginId5678 — Fri, 09 Mar 2018 12:31:30 GMT

This TSL1.2 upgrade has been bungled by authorize.net.

It turns out that production is different from the configuration deployed in their staging/test which everybody used to validate 1.2 compatibility!!!

Secondly, even now there is a difference in the TLS / Cipher between their akami production URL (https://api2.authorize.net/xml/v1/request.api) and the non-akami URL (https://api.authorize.net/xml/v1/request.api). With JDK1.7, we are able to hit staging and akami prod URL, but the very same codebase results in a SSLHandshake exception when targeting the non-akami URL.

Per their docs, both endpoints are valid, but it is highly unprofessional that they have different ciphers or configuration.