Regarding TLS disablement

[rizdplex123]

Hello Support Team,

We received an email notification from Authorize.Net about the TLS disablement on Sandbox and Production environment.

While performing test credit card transactions from our .NET application on Authorize.Net Sandbox we were getting an error related to TLS because TLS has been disabled on Sandbox environment. To fix this error we have made code changes to support TLS 1.2 in our application as suggested on the blogs and now we can perform test credit card transactions with no issues.

In addition to TLS disablement, Authorize.Net plans to retire 3DES in production on September 18th 2017. We referred API Best Practices for cipher recommendations and got to know that by using site https://www.howsmyssl.com/a/check we can validate cipher list.

From our application, we connect site https://www.howsmyssl.com/a/check and got following JSON response:

{

      "given_cipher_suites":

            [     "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",

                  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",

                  "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",

                  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",

                  "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384",

                  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",

                  "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",

                  "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",

                  "TLS_RSA_WITH_AES_256_GCM_SHA384",

                  "TLS_RSA_WITH_AES_128_GCM_SHA256",

                  "TLS_RSA_WITH_AES_256_CBC_SHA256",

                  "TLS_RSA_WITH_AES_128_CBC_SHA256",

                  "TLS_RSA_WITH_AES_256_CBC_SHA",

                  "TLS_RSA_WITH_AES_128_CBC_SHA",

                  "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",

                  "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",

                  "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",

                  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",

                  "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",

                  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",

                  "TLS_DHE_DSS_WITH_AES_256_CBC_SHA256",

                  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",

                  "TLS_DHE_DSS_WITH_AES_256_CBC_SHA",

                  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA",

                  "TLS_RSA_WITH_3DES_EDE_CBC_SHA",

                  "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA",

                  "TLS_RSA_WITH_RC4_128_SHA",

                  "TLS_RSA_WITH_RC4_128_MD5"

            ],

      "ephemeral_keys_supported": true,

      "session_ticket_supported": true,

      "tls_compression_supported": false,

      "unknown_cipher_suite_supported": false,

      "beast_vuln": false,

      "able_to_detect_n_minus_one_splitting": false,

      "insecure_cipher_suites": {

            "TLS_RSA_WITH_RC4_128_MD5": ["uses RC4 which has insecure biases in its output"],

            "TLS_RSA_WITH_RC4_128_SHA": ["uses RC4 which has insecure biases in its output"]

      },

      "tls_version": "TLS 1.2",

      "rating": "Bad"

}

In the above response, the rating is bad and there are two insecure ciphers related to RC4 but not about 3DES.

With this current settings, do you think 3DES retirement on Authorize.Net Production will cause any issues within our application while performing credit card transaction via Authorize.Net? If yes, what necessary code changes or server settings we need to configure at application/server level? Please suggest.

Thanks,
Riz

[NexusSoftware]

RC4 is insecure. https://support.microsoft.com/en-us/help/2868725/microsoft-security-advisory-update-for-disabling-rc...

3DES is slow and weak.

Removing insecure SSL ciphers will vary depending on your operation system.

For Windows you would use the “Run” dialogue box, type “gpedit.msc” and click “OK” to launch the Group Policy Editor. Select Computer Configuration > Administartive Templates > Network > SSL Configuration Settings:

In the right pane , double click on SSL Cipher Suite Order. The default is "Not Configured", select "Enabled", then paste your selected cypher suites into the text box labeled SSL Cipher Suites:

A starting point for your cipher suites would be the following:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

For Apache webserver

Open your httpd.conf or ssl.conf file and search for the SSLCipherSuite directive. If you can’t find it anywhere, you can just add it, otherwise, replace it with the following:
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)

On Nginx

ssl_prefer_server_ciphers On;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

Note the list of recommended cipher suites changes, so best practise is to keep apprised of discovered vulnerabilities and current recommendations.

https://wiki.mozilla.org/Security/Server_Side_TLS

[rizdplex123]

Thank you for quick response. Just want to confirm, if the recommended configuration settings are not applied on our application server then do we face any issues while performing payment transaction from our application to Authorize.Net gateway?

[NexusSoftware]

No, you shouldn't have any problem, as cipher suites are only used to negotiate encryption and HMAC algorithms. The cipher suite order determines, starting from the top, which ciphers will be preferred by the server.

With that being said, though not pertaining directly to your application's interaction with Authorize.net, even if higher grade ciphers are supported and normally used, some misconfiguration in the server can be used to force the use of a weak cipher - or worse no encryption - permitting to an attacker to gain access to the supposed secure communication channel.