Final Update: The POODLE vulnerability is being tracked by the Common Vulnerabilities and Exposures database. See CVE-2014-3566 for details.
Update: SSLv3 has already been disabled in the sandbox so you may test your solution. We have added a section to explain in greater detail how to perform testing in the sandbox.
If you have further questions about POODLE, please visit our Integration and Testing forum at http://community.developer.authorize.net/t5/Integration-and-Testing/POODLE-Internet-Security-Issue/t...
X-Cart users may download an upgrade that fixes SSLv3 issues. You may find it here:
http://blog.x-cart.com/SSLv3-shutdown-Nov-19th.html
Zen Cart also has an upgraded AIM payment module that fixes SSLv3 issues. You may find it here:
http://www.zen-cart.com/showthread.php?215145-Poodle-Help-Fix-it-s-not-working!!!&p=1263564#post1263...
As you may be aware, an Internet-wide security issue, commonly referred to as POODLE, has been identified in the last two weeks that creates a vulnerability that could allow hackers to gain access to any connection using this outdated Web browser.
Authorize.Net itself is not vulnerable to POODLE, but we are making changes to our systems to assure that we are providing our merchants and their customers with the highest degree of security possible.
To that end, on November 4, 2014, we will be disabling the use of SSL version 3 within our systems. This means that if your website or payment solution uses SSL version 3 to send transactions to Authorize.Net, your merchants will no longer be able to process transactions. You will also no longer be able to access any secure Authorize.Net pages.
Please be sure to update any sites or solutions that may be using SSL version 3 to post transactions to Authorize.Net.
The following information is provided to help you test whether you use SSL version 3, and to help you disable it.
BEST PRACTICES
To encourage security best practices, Authorize.Net strongly recommends using the highest version of TLS your configuration will support. For most configurations this should be TLS 1.2.
We also recommend including support for TLS 1.1, in case there are issues with your current TLS 1.2 configuration.
We will allow TLS 1.0 connections as well, but as a best practice we recommend using TLS 1.0 as an option of last resort. We may discontinue support for TLS 1.0 at a future date.
Connections that require SSL v3 will be refused. However, your server may continue to support SSL v3 as long as it uses TLS as its preferred protocol. We recommend disabling SSL v3 as a security best practice, regardless.
TESTING
To test your externally facing server configuration for TLS support, visit https://www.ssllabs.com/ssltest/index.html.
You can compare the results to the Authorize.Net SSL configurations to maximize compatibility with the protocols and ciphers we support:
For internal servers, a vulnerability scanner or vulnerability management suite may be needed. Here are a few possible options for you. (Note, these are not recommendations--Authorize.Net does not endorse the use of a particular product, nor do we claim a product is suitable for all uses.)
https://www.trustwave.com/Services/SpiderLabs-Services/Vulnerability-Management/ (commercial)
https://www.qualys.com/enterprises/qualysguard/vulnerability-management/ (commercial)
http://www.tenable.com/products (commercial)
http://www.bolet.org/TestSSLServer/ (open source)
http://code.google.com/p/sslaudit/ (open source)
VALIDATION
Once you have tested your solution and have determined it does not depend on SSL version 3, you may want to connect to our Sandbox environment and confirm that it works. All API endpoints in Sandbox have SSL version 3 disabled already, so testing here will confirm you can connect to our Production servers once we disable SSL version 3 there.
Note: You will need a Sandbox account to validate against these API endpoints. Visit https://developer.authorize.net/sandbox/ to create a Sandbox account.
Name-Value Pair API connections (AIM, Card Present API): https://test.authorize.net/gateway/transact.dll
XML connections: https://apitest.authorize.net/xml/v1/request.api
SOAP connections: https://apitest.authorize.net/soap/v1/Service.asmx
.NET
Use the SecurityProtocol property to enable TLS.
For details on how to use the SecurityProtocol property, visit:
http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol(v=vs.110).as...
http://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx
As an example, to force TLS 1.2 in a C# .NET implementation, you'd use:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
JAVA
NOTE: TLS 1.2 was first supported in JDK 7, and will be default in JDK 8: https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls
Use the SSLContext.getInstance method to enable TLS.
For details on how to use the SSLContext.getInstance method, visit:
http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String)
http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String,...
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext
For example, to use the default security layer provider to enable TLS, you'd use:
object = SSLContext.getInstance("TLS");
To force TLS 1.2 while using Sun's Java Secure Socket Extension (JSSE), you'd use:
object = SSLConnect.getInstance("TLSv1.2", "SunJSEE");
cURL
Use the CURLOPT_SSLVERSION option to enable TLS.
For details on how to use the CURLOPT_SSLVERSION option, visit:
http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html
As an example, to force cURL to use TLS 1.0 or later, you'd use:
C/C++/C#:
curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);
PHP:
curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);
In cURL 7.34.0 or later, to force TLS 1.2, you'd use:
C/C++/C#:
curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
PHP:
curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
