Post by exit15 » Sun Mar 04, 2018 9:19 pm

On 2/28 Authorize.Net disabled TLS 1.0/1.1 and customers can no longer check out with this payment method. Can't believe that there is no update for relevant files for OC v1.5.x. - did I miss something? I tested my server with https://www.ssllabs.com/ssltest/ and it was compatible with TLS 1.2 so I'm guessing its a code problem.

Can anyone suggest a solution for this problem? Customers are getting this message:
CURL ERROR: 35::Cannot communicate securely with peer: no common encryption algorithm(s).

Thanks much

New member

Posts

Joined
Sun Mar 03, 2013 2:05 am


Post by straightlight » Sun Mar 04, 2018 9:39 pm

See this post: https://community.developer.authorize.n ... rue#M24145 noticing if this is a coding issue with Opencart.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by exit15 » Sun Mar 04, 2018 10:01 pm

Posting my SSL test in case this is a server issue - advice welcome

Code: Select all

Cipher Suites
# TLS 1.2 (server has no preference)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK	112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)   DH 2048 bits   FS   WEAK	112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)   ECDH secp521r1 (eq. 15360 bits RSA)   FS   WEAK	112
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK	128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 2048 bits   FS	128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)   WEAK	128
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 2048 bits   FS	128
TLS_RSA_WITH_SEED_CBC_SHA (0x96)   WEAK	128
TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x9a)   DH 2048 bits   FS	128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 bits RSA)   FS	128
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   WEAK	128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)   DH 2048 bits   FS	128
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)   WEAK	128
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)   DH 2048 bits   FS	128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp521r1 (eq. 15360 bits RSA)   FS	128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp521r1 (eq. 15360 bits RSA)   FS	128
TLS_RSA_WITH_RC4_128_MD5 (0x4)   INSECURE	128
TLS_RSA_WITH_RC4_128_SHA (0x5)   INSECURE	128
TLS_RSA_WITH_IDEA_CBC_SHA (0x7)   WEAK	128
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)   ECDH secp521r1 (eq. 15360 bits RSA)   FS   INSECURE	128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK	256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 2048 bits   FS	256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)   WEAK	256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 2048 bits   FS	256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits RSA)   FS	256
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)   WEAK	256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)   DH 2048 bits   FS	256
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)   WEAK	256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)   DH 2048 bits   FS	256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp521r1 (eq. 15360 bits RSA)   FS	256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH secp521r1 (eq. 15360 bits RSA)   FS	256

New member

Posts

Joined
Sun Mar 03, 2013 2:05 am


Post by straightlight » Sun Mar 04, 2018 10:51 pm

Contact your host for these infos.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by Johnathan » Mon Mar 05, 2018 10:50 pm

This shouldn't require any actual changes to OpenCart code. What you need is for your server to default to TLS 1.2 for curl connections, which should then make any extension (including Authorize.net) use 1.2 for its connection. Contact your web host and ask them to make sure TLS 1.2 is the default connection for curl.

Image Image Image Image Image


User avatar
Administrator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by jamesross » Fri Mar 09, 2018 6:40 am

@johnathan - I have OC 1.5.4 installed on Windows 2008 SP2 (with TLS 1.1 and TLS 1.2 support installed) I have edited the registry and force the server to use TLS 1.2 and its verified in SSL Labs website. However I still get the handshake error with CURL saying SSLv3, etc..

How can we change in CURL to make the app use TLS 1.2, i've seen posts saying to edit the Authorize.Net AIM file (module) and make it specifically use TLS 1.2, but when I do that the shopping cart just hangs at please wait, when I try and process the test 4111 1111 1111 1111 visa.

Does the Authorize.NET AIM extension in OC 1.5.4 work with TLS 1.2?

Newbie

Posts

Joined
Fri Mar 09, 2018 6:28 am

Post by Johnathan » Sat Mar 10, 2018 12:54 am

You should contact your web host to do this. I'm not sure how to set the server to default to TLS 1.2 for curl, but they should know how to do it. (If they don't, find a new web host.)

If you want to try forcing the curl connection to use TLS 1.2, you can adding this in the /catalog/controller/payment/authorizenet_aim.php file:

------------------------------------------------------------------------------
AFTER:
curl_setopt($curl, CURLOPT_TIMEOUT, 10);

ADD:
curl_setopt($curl, CURLOPT_SSLVERSION, 6);
------------------------------------------------------------------------------

Image Image Image Image Image


User avatar
Administrator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by exit15 » Fri Apr 13, 2018 5:53 am

I finally got around to fix this issue with TLSV1.2 and Authorize.net. There ate two separate changes that need to take place:
1. Server SSL protocol. You need to make sure that only TLSv1.2 is active. To do so first run this command to see which protocols are active

Code: Select all

/usr/local/psa/bin/server_pref -s | grep ssl-protocols

Then run this to make only v1.2 active

Code: Select all

/usr/local/psa/bin/server_pref -u -ssl-protocols TLSv1.2
If you run the first command you should now see this: ssl-protocols: TLSv1.2
Restart your server

2. This has to do with Opencart and as suggested by Johnathan it will fix the CURL Error 35: curl unable to communicate securely with peer
Open /httpdocs/catalog/controller/payment/authorizenet_aim.php
add this line (around line 111)

Code: Select all

curl_setopt($curl, CURLOPT_SSLVERSION, 6);
just below this line

Code: Select all

curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 10);
Now you should be good. Remember PayPal will enforce this about June 2018, so u better be done now.

thanks all -- a

New member

Posts

Joined
Sun Mar 03, 2013 2:05 am


Post by straightlight » Fri Apr 13, 2018 9:13 am

Thanks for the documentation. It will certainly help people in the future. However, to specify that the SSH console may be needed to apply the command lines would be useful to know.
Now you should be good. Remember PayPal will enforce this about June 2018, so u better be done now.
Any official documentation you could provide based on these validations that needs to be done for June 2018 from PayPal?

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by exit15 » Fri Apr 13, 2018 12:07 pm

its on the PayPal notices website and got an email too
https://www.paypal-notice.com/en/

New member

Posts

Joined
Sun Mar 03, 2013 2:05 am


Post by midwestshades » Wed Jun 13, 2018 3:35 am

I am running into the same problem with hostgator and paypal. The sandbox testing isnt going through. I am running OC 1.5.6.4. Host gator has tls 1.0, 1.1, 1.2. However I think they need to make 1.2 the default tls. for my shared server but there acting like they cant do that. Saying I should buy a dedicated server. I am wondering if i need to update any files in my website as to force a tls version. June 30th is the day they go live with the tls 1.2 only. Not sure what to do... Help please

Newbie

Posts

Joined
Wed Jun 13, 2018 1:25 am

Post by Johnathan » Wed Jun 13, 2018 5:31 am

For others that read this, see my response to midwestshades' other post here:

viewtopic.php?f=20&t=205053&p=726297#p726319

Image Image Image Image Image


User avatar
Administrator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by exit15 » Wed Jun 13, 2018 1:41 pm

With Authorize.net payment removing TLS 1.0 and 1.1 from the server was not enough.
Had to add this line to controller/payment/authorizenet_aim.php

Code: Select all

curl_setopt($curl, CURLOPT_SSLVERSION, 6);
Recently upgraded to OC 3.0.2.0 and I had to make the same change to controller/extension/payment/authorizenet_aim.php
Otherwise your get an error! The curl_setopt($ch, CURLOPT_SSLVERSION, 6); is requesting TLS v 1.2

Why not try adding it in controller/extension/payment/pp_pro.php - around line 135.
Let me know if it works.

New member

Posts

Joined
Sun Mar 03, 2013 2:05 am


Post by Johnathan » Wed Jun 13, 2018 9:31 pm

If your web host properly turned off TLS 1.0 and 1.1 (and all SSL versions) then there's no other way for curl to connect than TLS 1.2. Most likely, your web host told you that 1.0 and 1.1 were turned off, but that didn't actually happening. Forcing the connection to TLS 1.2 is fine, but it's not the ideal solution (since anything else using curl that you don't specify the curl_setopt() for will use a less secure version.

Image Image Image Image Image


User avatar
Administrator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by exit15 » Thu Jun 14, 2018 2:42 am

Well, first it will be good for everyone to know that it can be "forced" because not everyone has full control their hosting environment. I don't know about other things using curl, but authorize.net gateway simply did not work, unless it was specified in the code.

I have full control of my hosting environment and running this command in SSH

Code: Select all

/usr/local/psa/bin/server_pref -s | grep ssl-protocols
returns this

Code: Select all

ssl-protocols:	TLSv1.2
Showing that I have successfully deactivated TLS 1.0 and 1.1

Before doing this, I had three versions of TLS, what's to say which one is the default? And what is to say if Authorize or PayPal are asking for the default version. I only know that the de facto behavior was not to ask for the highest version AND that even after deactivation of lower versions, it still wanted us to specify the SSL version in the code. Go figure.

With respect to pay-pal, currently it is working for me without any changes to the code (using PP Express Checkout), but I am not sure what will happen come June 30th. I would like to know if others tried this in sandbox mode.

New member

Posts

Joined
Sun Mar 03, 2013 2:05 am

Who is online

Users browsing this forum: No registered users and 133 guests