topic Re: POODLE Internet Security Issue in Integration and Testing

POODLE Internet Security Issue

RichardH — Tue, 04 Nov 2014 20:27:00 GMT

Thread for follow-up questions related to POODLE blog post at http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Important-POODLE-Information-Updated/ba-p/48163

Re: POODLE Internet Security Issue

RichardH — Wed, 05 Nov 2014 01:20:08 GMT

The planned SSLv3 deprecation is complete. For more info, please visit our FAQs at http://www.authorize.net/support/poodlefaqs/

Richard

Re: POODLE Internet Security Issue

Lilith — Wed, 05 Nov 2014 23:17:56 GMT

We have noticed some merchants have applied POODLE fixes asymmetrically.

For example, the server may have SSLv3 disabled, but the code may attempt to force SSLv3 anyway, causing connection issues.

Similar connections issues may occur if you try to force TLS 1.2 without ensuring your server can support TLS 1.2.

As a best practice, we recommend not forcing TLS or SSL in code, and letting the server use its defaults, which typically have the strongest security features. If you must force a security protocol, TLS 1.2 is recommended, but in general you may be able to force TLS without versioning for greater flexibility.

Re: POODLE Internet Security Issue

webspinners — Thu, 06 Nov 2014 15:54:12 GMT

We have updated our server to disable SSLv2 and SSLv3 and only use TLS1.0 but we continue to get a "Unknown Error" when posting transactions via AIM. We have tested the site/server using the Poodlescan and SSLlabs websites and they say we are good.

Can anyone shed some light? We are running Win2003 Server Enterprise Edition with ColdFusion as the programming language.

Re: POODLE Internet Security Issue

Lilith — Fri, 07 Nov 2014 03:04:57 GMT

Which version of ColdFusion does your server use? And are you willing to share the code that connects to our API?

While I await your answer I will research whether there are ways to force ColdFusion to use TLS, or whether there is a specific version that you must use.

Re: POODLE Internet Security Issue

Lilith — Fri, 07 Nov 2014 03:15:40 GMT

One other thing: Which ciphers are supported by your server? For that matter, would you be willing to share an SSL Labs report for the server, or an equivalent?

Re: POODLE Internet Security Issue

jms — Fri, 07 Nov 2014 16:36:58 GMT

We're having problems as well connecting to secure.authorize.net. Our site is running on IIS 6.0 with ColdFusion 5. I've run the SSL labs tool against our server and secure.authorize.net, and the only difference that I can see is that ours has an SHA2 certificate. Would that be a problem? We've been getting a Connection Failure response ever since Nov 4.

Re: POODLE Internet Security Issue

Lilith — Fri, 07 Nov 2014 16:39:40 GMT

SHA2 shouldn't be a factor, but it's entirely possible there is an element in your code that is attempting to use SSLv3. Is your installation pure ColdFusion? Or does it connect to us using something like cURL or Java?

Also, would you be willing to share your SSL Labs report with us?

Re: POODLE Internet Security Issue

jms — Fri, 07 Nov 2014 17:22:47 GMT

Pure ColdFusion.

I can share our SSL Labs report. How would you like me to share it?

Re: POODLE Internet Security Issue

bwalleshauser — Fri, 07 Nov 2014 17:31:34 GMT

We're having issues connecting via TLS 1.0 (even though authorize.net says it will work). Our ssllabs report is actually better than authorize.net's and it still won't connect. Could this be the problem in your case?

Re: POODLE Internet Security Issue

jms — Fri, 07 Nov 2014 17:36:05 GMT

Sounds pretty similary. Are you running ColdFusion too?

Re: POODLE Internet Security Issue

jms — Fri, 07 Nov 2014 17:41:16 GMT

Testing in Fiddler, I get "No proxy-authenticate header is present" and "no www-authenticate header is present". We've been using this code for years, so some requirement may have changed. Is there a specific proxyserver I should be specifying in my request?

Re: POODLE Internet Security Issue

webspinners — Fri, 07 Nov 2014 18:17:28 GMT

Yes, we are also using CF5 Enterprise Ed on a Win203 Server Enterprise Ed. We upgraded from 2000 Server when we began having this problem on the 4th to get TLS1.0 support. Though, after some other testing on another 2000 Server SSL site it appears it already had TLS1.0 support??
We disabled SSLv2 and v3 in the registry so it can only use the TLS1.0 but since we are still getting this UNKNOWN ERROR on the AIM transaction we are beginning to think it has to be that CF5 forces SSLv3 rather than the server default when doing a CFHTTP post to the AuthNet gateway. I don't mind sharing report or code. We have several custom order apps that use our AIM and CF5 solution and all are getting this same UNKNOWN ERROR.
https://www.ssllabs.com/ssltest/analyze.html?d=shop.vs2000.net&hideResults=on provides more info than the POODLESCAN.COM site report.
As for code... I will put it in the next message. Not Rocket science so I'm not too worried about other users "Stealing" my code. It may help them write better CF apps for AIM...

- Michael

Re: POODLE Internet Security Issue

jms — Fri, 07 Nov 2014 18:27:27 GMT

Thanks. I don't think Server 2003 is the problem - we've been using 2003 R2 for years and never had this problem. I'm leaning towards the same conclusion - that CF5 forces SSL v3. Still testing more...

Re: POODLE Internet Security Issue

webspinners — Fri, 07 Nov 2014 18:28:30 GMT

The UNKNOWN ERROR does come from our code when it gets a response from AuthNet that is other than 1,2,3,4...see near the bottom of this code.
We do a secure post to this page AuthNetAim.cfm which then posts and gets info from AuthNet and displays a THANKS or Error info and then process further approved orders.

Thanks in advance ALL for any help. I see I am not the only one using a CF5/Win2000/2003 AIM code.

-Michael
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<cfset Delimiter=",">

</cfhttp>

<cfoutput>
<CFSCRIPT>
/**
* Fixes a list by replacing null entries.
* This is a modified version of the ListFix UDF
* written by Raymond Camden. It is significantly
* faster when parsing larger strings with nulls.
*
* @Param list The list to parse.
* @Param delimiter The delimiter to use. Defaults to a comma.
* @Param null Null string to insert. Defaults to "".
* @return Returns a list.
* @author Patrick McElhaney (pmcelhaney@amcity.com)
* @version 2, February 14, 2002
*/
function ListFix(list) {
var delim = ",";
var null = "Null";

if(arrayLen(arguments) gt 1) delim = arguments[2];
if(arrayLen(arguments) gt 2) null = arguments[3];

list = replace(list,"#delim##delim#", "#delim##null##delim#", "ALL");
list = replace(list,"#delim##delim#", "#delim##null##delim#", "ALL");

if (left(list, 1) eq delim) list = "#null##list#";
if (right(list, 1) eq delim) list = "#list##null#";
return list;
}
</CFSCRIPT>

<cfset TheList=ListFix(CFHTTP.FileContent)>
<cfset TheDelimiter=Delimiter>

<cfset ProcessorResponse="UnknownError">


<cfif ListGetAt(TheList,1,TheDelimiter) is "1">
<cfset ProcessorResponse="Approve">

<cfelseif ListGetAt(TheList,1,TheDelimiter) is "2">
<cfset ProcessorResponse="Decline">
<cfset DeclineReason=ListGetAt(TheList,4,TheDelimiter)>
   
<cfelseif ListGetAt(TheList,1,TheDelimiter) is "3">
    <cfset ProcessorResponse="Error">
<cfset ErrorCode=ListGetAt(TheList,3,TheDelimiter)>
<cfelse>
 

</cfif>
</cfoutput>

<HTML>
<HEAD>
<title> Secure Invoice</title>
</HEAD>

<table width="1000" border="0" align="CENTER" valign="TOP">
<CFOUTPUT>

<cfif ProcessorResponse is "Approve">
<H3 ALIGN="CENTER">Thank you for placing your order online.
<br><br>

</H3>
<h4 align="center">To cancel or change your order you must contact us </h4>

<cfelseif ProcessorResponse is "Decline">
   <div align="center">The transaction was not approved.<br>
       Reason: #DeclineReason#<br>
</div>
   
<cfelseif ProcessorResponse is "Error">
    <div align="center">There was an error processing the transaction.(#ErrorCode#)</div>
<cfelse>
 
  Unknown Error
</cfif>
</cfoutput>

</td>
</tr>
</table>

</BODY>
</HTML>

Re: POODLE Internet Security Issue

bwalleshauser — Fri, 07 Nov 2014 19:08:35 GMT

Using wireshark, we discovered our problem was that Authorize.net doesn't send a response back to us after we make a request. We didn't receive a gateway error, but an EOF error. This leads me to believe that TLS 1.0 is being blocked, since at the very least, we'd get a gateway error.

Re: POODLE Internet Security Issue

webspinners — Fri, 07 Nov 2014 19:39:24 GMT

One of my developers has suggested that they are blocking/not supporting TLS1.0 anymore and that is why the connection is closed as if it was SSLv3. AuthNet does say they plan to disable support for TLS1.0 at some future time. Perhaps they already did and we are really screwed and must upgrade to 2008 or 2012 WinServer to get TLS1.1 or 1.2 support. That would be bad and expensive to change over here.

For the interm we are looking into using SIM to eliminate SSL at all and also using a ASP or PHP file to act as the AIM connector between our CF and Authnet Secure servers. Frankenstein app...but if TLS1.0 is not supported that won't work for AIM on win2003 either!

Re: POODLE Internet Security Issue

bwalleshauser — Fri, 07 Nov 2014 22:31:03 GMT

We're planning on hijacking the call, sending it to a separate server, and sending it that way

Re: POODLE Internet Security Issue

webspinners — Fri, 07 Nov 2014 22:36:45 GMT

The SSLLabs report on secure.authorize.net shows it does support TLS1.0 so it should be working with 2003 server if sslv3 and v2 are disabled on it.

Re: POODLE Internet Security Issue

Lilith — Wed, 12 Nov 2014 18:20:33 GMT

@webspinners Correct, we have not disabled TLS 1.0 yet, and it's not clear when we will.

The comment about TLS 1.0 is forward-looking, and reflects the facts that TLS 1.3 is under development, and that security issues with TLS 1.0 are becoming better-known, so inevitably we'd need to disable TLS 1.0 for the same reasons we disabled SSL v2 and v3. It's not clear when that'd happen, however. While disabling SSLv3 is an option for nearly every solution, TLS 1.0 is the last, strongest security protocol for Windows Server 2003 and 2008, and for any minor version of OpenSSL prior to 1.0.1.

While the nature of POODLE required swift action, we're hoping for a much more gradual process for decommissioning TLS 1.0 when the time comes. In the meantime, I do encourage upgrading to Windows Server 2008 R2/OpenSSL 1.0.1 or greater.