The Authorize.Net Developer Blog

Posts from Authorize.Net employees, community members and experts about integrating with the Authorize.Net Payment Gateway: sample code, tutorials, and problem-solving techniques, just to name a few.

Important POODLE Information - Updated

by Administrator Administrator on ‎10-27-2014 03:22 PM - last edited on ‎11-12-2014 09:27 AM by Administrator Administrator (569,030 Views)

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);

 

 

Comments
by pahcal123
on ‎10-28-2014 08:55 AM

My web sites that use Authorize.NET use the Direct Post Method (DPM) and Server Integration Method (SIM) methods. Since neither of these methods involve making a request from my server to Authorize.NET, I assume that I don't need to make any changes. Is that right? My customers might be using a browser that uses SSLV3, but I can't control that.

by mcarbone
on ‎10-28-2014 11:08 AM

Can you say a little more about: "Authorize.Net itself is not vulnerable to POODLE"? Why is this the case if SSLv3 is still enabled?

 

Thanks,

-marco

by jgodish
on ‎10-28-2014 11:21 AM

What error will you get back in sandbox if you are using SSLv3?

by ckulow
on ‎10-28-2014 11:24 AM

What type of error message would a customer see when using IE 6 to access secure Authorize.Net web pages?

by jgodish
on ‎10-28-2014 11:49 AM

Is there any specific way the CIM api needs to be used so as not to use SSLv3?

by mdowdie
on ‎10-28-2014 12:42 PM

I need a way to test a shopping cart that uses AIM please.

by HTCSystems
on ‎10-28-2014 12:52 PM

Is there a way for me to scan to verify all the proper changes are made, and that the changes on 11/4 will not affect our operations.

by mdowdie
on ‎10-28-2014 01:43 PM

The lack of detailed information, lack of any apparent way to test shopping carts using the API, and the very short notice on this are really unacceptable. 

 

This is not really an emergency situation but Authorize.net is forcing merchants to drop everything and deal with this in a very short time period or risk being unable to do business in a few days.  We need a better (or any) way to test and more time to test.

by Administrator Administrator
on ‎10-28-2014 02:06 PM

@pahcal123, you should be all right, but you may want to make sure your Relay Response/Silent Post URLs are hosted on a server that has proper support for TLS. If you aren't using Relay Response or Silent Post then you should be in great shape.

@mcarbone POODLE is mitigated if SSL v3 is used with the RC4 cipher, as RC4 is not vulnerable to padding attacks like POODLE. That said, SSL v3 is still not sufficiently secure, and so we are ending support for it.

@jgodish This isn't at the API level, but at a lower level in your code, possibly configured at the server level. If you attempt to connect to a server with SSL v3 and that server doesn't support SSL v3, the connection will be refused.

 

@ckulow We don't have a copy of IE6 to test with, but if you use a browser that only supports SSL to connect to a server that only supports TLS, the connection will be refused. IE is likely to display its standard "page cannot be displayed" error.

by dmmc
on ‎10-28-2014 04:24 PM

Just to make double triple sure, I tested our AIM software using https://test.authorize.net/gateway/transact.dll and it works fine and I can see the transactions listed on the sandbox.authorize.net website.  If it was sending SSL3 then I assume it would have failed, but since it worked then all will be cool Nov 4.  Please confirm - thanks!

by atlantisnet1
on ‎10-28-2014 04:24 PM

Is there a way we can test our applications to make sure they will work after November 3?  Does the test/development server (https://test.authorize.net/gateway/transact.dll) have SSL 3.0 disabled?

by Administrator Administrator
‎10-28-2014 05:17 PM - edited ‎10-28-2014 05:19 PM

@dmmc, @atlantisnet1:

 

Yes, as stated in the original post, our sandbox environment--which includes https://test.authorize.net/gateway/transact.dll,

https://apitest.authorize.net/xml/v1/request.api, and https://apitest.authorize.net/soap/v1/Service.asmx--has SSL v3 disabled. We encourage developers to test against this to confirm that their solution will work without SSL v3.

Also, we provide additional resources for your troubleshooting needs in the original post, including options for scanning your servers to see if SSL v3 is enabled.

 

by Contributor linvio
‎10-28-2014 06:18 PM - edited ‎10-28-2014 06:19 PM

We are working with Salesforce to get them to update their platform and use TLS (instead of SSL v.3) for outbound calls, but they have not given us a date by which they'll have the changes finished.  Who can we appeal to in order to coordinate the change over gracefully?

by skumar10
on ‎10-29-2014 07:04 AM

We use the CIM method and webservice calls to  https://secure.authorize.net to retrieve the token to be used to post. How does this affect us ?

 

by HTCSystems
on ‎10-29-2014 07:28 AM

What I am looking for is a confirmation from Authorize.Net that my productions systems will not be turned off.  I have verified that SSL 3 is disabled at the server level in my production servers.  I have also verified that with the recommended scanners.  The scanner now indicates that "This server is not vulnerable to the Poodle attack because it doesn't support SSL 3".  Is this enough to verify I will not have my Authorize.Net turned off on 11/4/1?

by bernbe01
on ‎10-29-2014 07:58 AM

So if my server passes the test and is not vulnerable, and I am using the anet_php_sdk, are any further actions required?

 

I.E. If someone is using the official SDK, and the server is not vulnerable, is there any reason to make changes to the SDK library files?

by structuredweb
on ‎10-29-2014 08:00 AM

Hello,

 

we are connecting to auth.net from classic ASP code, on Windows 2003, using MSXML2.ServerXMLHTTP.4.0

 

i have tried testing the code using the test URL, https://test.authorize.net/gateway/transact.dll and using one of our client login and key, which i was sure its active, and im getting this reponse:

 

(TESTMODE) The merchant login ID or password is invalid or the account is inactive.

 

ddoes this mean that on the protocol level we are good? Pease advice ASAP, otherwise we have to scramble to be ready for Monday ...

 

by HTCSystems
on ‎10-29-2014 08:23 AM

I am sorry, but I cannot believe authorize.net is not monitoring this forum.  They put out an alert, indicating systems could be turned off in less than a week.  Then, do not promptly respond to inquiries from developers.  I would expecting them to have someone in this forum responding quickly to questions and comments.

by tungsten_rings
on ‎10-29-2014 08:24 AM
The SSLv3 being disabled should not have any effect on my all tungsten rings business. My shopping cart code uses the Openssl package which is installed by my hosting company for encryption. Openssl supports TLS which replaced the older SSL v3. Just checking a community forum of authorize.net guru's ..... does anybody know if authorize.net has upgraded the latest version of Openssl. I need the latest Openssl installed. The newest Openssl has some poodle related bug fixes. Thanks for any input. Gary
by Administrator Administrator
on ‎10-29-2014 09:09 AM

@linvio, as long as SalesForce supports TLS and isn't forcing SSL v3 to be negotiated first, you should be in good shape. Web servers and coding platforms have had TLS support since around 2005 or so, so I'd expect SalesForce to support TLS 1.0 at least. Also, according to Qualys, while their login page's SSL test score is rather low, they do offer support for TLS 1.0 and 1.2:

https://www.ssllabs.com/ssltest/analyze.html?d=login.salesforce.com&s=204.14.235.101

 

(I realize that their API hooks may not have the same security setup but the presense of TLS support on the login page is still encouraging.)


Would you confirm with them that they support TLS? They can disable SSL v3 at their leisure as long as they aren't insisting on connecting to us using SSL v3.

by Administrator Administrator
on ‎10-29-2014 09:11 AM

@skumar10 Please make sure that your web server and code isn't connecting to us using SSL v3. There are resources at the top of this post that your web hosting company, developers, etc. can use to confirm SSL v3 is not an issue.

by Administrator Administrator
on ‎10-29-2014 09:13 AM

@HTCSystems To be clear, we won't be turning anyone's account off. However, if your server attempts a connection to us using SSL v3 after November 4, we'd refuse the connection. Since your scanner indicates that SSL v3 is disabled, you should have no worries at all.

by Administrator Administrator
on ‎10-29-2014 09:18 AM

@bernbe01 That is a reasonable presumption. We performed a code review of the SDKs in preparation for this announcement and found nothing in the SDK code that implicitly set whether to use SSL or TLS.

Since there's nothing in the SDK to determine SSL/TLS, that means it's dependent on your server configuration and whether it supports SSL or TLS.

And since your server supports TLS only, you should be in good shape. I still advise connecting to Sandbox to confirm that your TLS configuration has ciphers compatible with ours, but we support a good number of TLS ciphers so that shouldn't be a serious issue.

by Administrator Administrator
on ‎10-29-2014 09:24 AM

@structuredweb You should be good then! Your test confirms that your current server and code configuration connects to us without relying on SSL v3.

That said, Windows Server 2003 only supports TLS 1.0, and I cannot rule out TLS 1.0 being discontinued in the future. For best security, we recommend you consider upgrading to Windows Server 2008 R2, which includes IIS 7.5, the first version of IIS to support TLS 1.1 and TLS 1.2.

by Administrator Administrator
‎10-29-2014 09:36 AM - edited ‎10-29-2014 11:01 AM

@tungsten_rings The fix you mention just adds a new call, TLS_FALLBACK_SCSV, which prevents POODLE with SSL v3 connections. In some environments that fix is sufficient. But given that SSL v3 has other security concerns and has modern replacements, it's best to disable the protocol entirely and gain protection from POODLE and a number of other potential exploits.

by snoonan
on ‎10-29-2014 10:01 AM

I have set up a sandbox account and am testing sending transaction via API to https://test.authorize.net/gateway/transact.dll. I'm doing this from a server that has SSL v3 enabled (i'm leaving it enabled to test if the sandbox actually rejects). The sandbox is not rejecting my connection. I'm want to verify that the sandbox will reject it so I can make changes on my server and then test for 11/4. Please advise

by Administrator Administrator
on ‎10-29-2014 10:56 AM

@snoonan Sandbox will only reject a connection if your server tries to use SSL v3 first, or as the only protocol. If it starts with any version of TLS, then the connection will be accepted.

This suggests to me that, while your server supports SSL v3 (and that you may want to disable it as a precaution) it is fully capable of handling TLS, and should be ready for the disabling of SSL v3 in Production next week.

by Lingna
on ‎10-31-2014 04:27 PM

I have a question about Silent Post.

I remember you were using SSLv3 to send Silent Post to our system, what about this on Nov. 4, 2014?

by Administrator Administrator
‎10-31-2014 04:51 PM - edited ‎10-31-2014 04:51 PM

@Lingna 

 

Authorize.Net will not support SSLv3 on November 4, 2014.  This includes the Merchant Interface, API Endpoints and Relay Response/Silent Post.

by Lingna
on ‎10-31-2014 05:10 PM

@Permalink,

 

Thanks for confirming this. Therefore I can completely disable SSLv3 in our server on November 4, 2014.

by seakayaker4life
on ‎11-01-2014 08:20 AM

FYI, when I attempted to process a payment with my developer account, it did NOT reject the connection and instead returned a Response Code of 3 with Response Reason Code of 261, which says "An error occured during processing. Please try again." but according to the Response Reason Code Tester actually means "The transaction experienced an error during sensitive data encryption and was not processed. Please try again."

 

I updated my configuration to force TLS 1.2 and the error went away.

 

It does not look to me like connections are being refused.

by smckenna5714
on ‎11-01-2014 09:30 AM

I have a windows 2003 server making AIM calls and when I test it against the sandbox I get a 'The remote certificate is invalid according to the validation procedure.' error (I assume that's AuthNET rejecting the SSL protocol). But when I run the scanner it says I'm OK with SSL 3.0 but it gets Key Exchange and Cipher Strength red flags. AIM calls to secure.authorize.net work fine. Any ideas?

by Administrator Administrator
on ‎11-03-2014 09:50 AM

@seakayaker4life Do you have a timestamp when you attempted that test? I cannot promise an immediate resposne but I'd like to see what we can find.

@smckenna5714 I don't think you're seeing SSL v3 issues. You should be receiving a response from developer@authorize.net with a suggestion to try.

by seakayaker4life
on ‎11-03-2014 11:18 AM

@LilithI am no longer sure it was related to the SSLv3 issue, as the error recurred later in the day after I had run several successful transactions under TLS 1.2. It was in my CNP test account and the response reason code 261 transactions occurred on November 1 at (Eastern Daylight Time) 10:45am, 10:47am, 10:51am, 10:59am, and then after I had moved to TLS 1.2 at 2:27pm. I have not had this issue since then.

by Administrator Administrator
on ‎11-03-2014 11:26 AM

@seakayaker4life You're right. There was an internal issue with the Sandbox environment during the times you mention, and the RRC 261s stem from that.

I'm curious if you were allowing SSL v3, or forcing SSL v3. The distinction is that if you allow SSL v3, but you also have support for TLS, in most cases TLS will take precedence. So if you were merely allowing it, that alone wouldn't cause a refused connection.

by seakayaker4life
on ‎11-03-2014 12:03 PM

@Lilith  Originally I had assumed that my web app, which connects via PHP curl, was preferentially using TLS. Then when I got this error I incorrectly attributed it to the SSLv3 issue, and assumed that PHP curl must have been defaulting to SSLv3 with no failover to TLS (which surprised me). But now I'm pretty sure my original assumption was correct, as you point out. Thanks for the help.

by Big_A
on ‎11-04-2014 11:08 AM

OK, it's November 4th, 1:07 CST. Has the transition happened? If not, what time?

by cjbillings
on ‎11-04-2014 11:08 AM

@ Lilith   Can you confirm when the production servers were changed today to eliminate any SSL3.0 connections?  If it has not occured, what is the schedule?

 

Thank you

by Administrator Administrator
on ‎11-04-2014 12:23 PM

@Big_A and @cjbillings -- the release will start after 5 PM Pacific time today.

by Administrator Administrator
on ‎11-04-2014 12:27 PM

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...