Updating Authorize.net since TLS 1.0 and 1.1 is now deprecated

Question

Background

I have taken over a making updates to a site that was running a very old version of PHP. After moving the site from 5.3 to 7.1 I have since noticed that authorize.net keeps sending out emails stating,

we will no longer allow TLS 1.0 and 1.1

It states that it will completely stop working within the next few weeks and I am not sure how to know if the site uses this deprecated version of TLS or not. I assume I should be able to know by the authorize.net classes in the application. But the code does not in any way reference TLS. I also assumed I could know by the endpoints being used, but I have yet to see anything regarding the version of TLS being used having to do with the endpoint being used.

Does anyone know of a sure fire way to test and know if we are indeed using an older version of TLS in our site? Or if it is possible we are using a very old version of authorize.net in the site that does not rely on TLS at all?

Example Code

These are beginning of a few of the classes used in the application. Maybe someone has some understanding of what specifies the version of TLS you are using by the version of the authorize.net api you are using.

class.aim.cc.license.php

<?php
/*********************/
/*                   */
/*  Dezend for PHP5  */
/*         NWS       */
/*      Nulled.WS    */
/*                   */
/*********************/

class authnetcc
{

    var $fields = array( );
    var $license_key;
    var $gateway_url = "https://secure.authorize.net/gateway/transact.dll";
    var $proxy_url;
    var $proxy_port;
    var $secure_source = false;
    var $error_code;
    var $error_message;
    var $error_field;
   ...

AIM.class.php

<?php
/**
* CLASS AIM
*
*
*/
class AIM {
    // login credentials that Authorize.net uses for verification
    var $login_id = '';
    var $trans_key = '';

    // server
    var $server = '';

    // credit card information
    var $cc_name = '';
    var $cc_number = '';
    var $cc_month = '';
    var $cc_year = '';
    var $cc_code = '';
    var $cc_type = '';

    // error stack array
    var $errorStack = array();

    // modes
    var $testMode = false;
    var $debugMode = false;
    var $errorRetries = 2;

    // buyer information
    var $buyer = array();

    // response information
    var $status = '';
    var $subcode = '';
    var $response_code = '';
    var $response_text = '';
    var $approval_code = '';
    var $md5hash = '';
    var $code = '';
    var $remaining = array();

    // constructor
    function __construct($login_id, $trans_key) {
        $this->login_id = $login_id;
        $this->trans_key = $trans_key;

        $this->setTesting(0);
    }
    ...

`Dezend for PHP5`.. buy your scripts don't steal them, if something makes you money support the guy/s who built it!.. — Lawrence Cherone, Feb 11 '18 at 02:40
your code is not at issue, you need to check the server its running on — , Feb 11 '18 at 02:47
@LawrenceCherone Did you read my question? I did not buy or steal anything. This is a site that is ten years old.I am simply trying to look through the site and figure out what needs to change to make sure it stay up and running. Would you please be so kind to clarify your concerns? — wuno, Feb 11 '18 at 02:48
@rtfm that makes so much more sense to me. I would think this only has to do with SSL or the end point being used. Can you tell me what would need to be confirmed on the server to make sure we are using the correct version of TLS? If at all? This is a up to date Centos7 Cpanel server. — wuno, Feb 11 '18 at 02:52
`openssl s_client -connect www.google.com:443 -tls1_2` from the command line — , Feb 11 '18 at 02:55
@rtfm I ran the command and can see that it says, Protocol : TLSv1.2. So I see the server is using 1.2 but can that guarantee that the php application is as well? — wuno, Feb 11 '18 at 03:31
@LawrenceCherone if you're going to accuse a poster of theft could you provide some more context for your attack? The poster made no claim that this was code they'd written. — Dave S, Feb 11 '18 at 04:30

John Conde · Accepted Answer · 2018-02-11T16:58:39.827

3

This is not a coding issue. Authorize.Net has been sending these emails out for over a year. They, like every other PCI compliant payment gateway, are required to use TLS 1.2 or better to remain PCI compliant and this means all of their customers must be compliant as well. This is something you configure on your server, not in your PHP code. If you are using a shared web hosting provider you need to contact them and ask to be moved to a server that supports TLS 1.2 or find a new host that supports it.

FYI, you should also use the new Akamai URL for their API which also must be updated. The correct URL to use going forward is https://api2.authorize.net/xml/v1/request.api.

edited Feb 11 '18 at 16:58

answered Feb 11 '18 at 15:58

John Conde

217,595
99
455
496

Thank you for your help.I have verified that https://secure.authorize.net/gateway/transact.dll will no longer work on the 28th. Do you know if changing this URL out with the new production URL from authorize.net will break the app? Or if swapping the URL out will not break anything? Or if there is info about the breaking changes anywhere? – wuno Feb 11 '18 at 18:25
Swapping the URL out break anything. Changing both the TLS version and new endpoint URL should be transparent to your code. – John Conde Feb 12 '18 at 01:46

Updating Authorize.net since TLS 1.0 and 1.1 is now deprecated

1 Answers1