Request for Comments: API Best Practices

[Lilith]

We just posted a draft of our upcoming API Best Practices Guide.

Please post your feedback below. Thanks!

[npiasecki]

For example, in .NET 4.5, TLS 1.2 is enabled by default. Upgrading to .NET 4.5 should provide your solution with support for TLS 1.2.

That enables it in the platform, but you still need to interact with System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; to enable the use of TLS 1.2 (while keeping TLS 1.0 for other services you may contact that are not yet enabled for modern TLS) on outbound connections, somewhere in your application startup. By default, an HttpWebRequest or WCF client will use only SSL 3.0 and TLS 1.0 for outbound connections. (Inbound connections to your Windows server are controlled by registry settings which are easily managed by a tool called IIS Crypto and are independent of the .NET Framework version.) 

http://stackoverflow.com/a/29221917/32187

If you're unable to make code changes to your application to change the flags passed into SecurityProtocol, you can force all .NET applications on the machine to use TLS 1.2, 1.1, and 1.0 if available by setting a different registry setting.

http://stackoverflow.com/a/28502562/32187 and http://stackoverflow.com/a/34009938/32187

Hope this helps someone.

[mikeada]

npiasecki: I was about to post the same thing, nice post.  

The Best Practices article should be updated to remove this inaccurate text and say something of the following instead "In .NET 4.5, TLS 1.2 is supported, but NOT enabled by default.  You must set the SecurityProtocolType to enable TLS 1.2.

This is going to be a MAJOR issue come 2017 when Authorize.net disables TLS 1.0 and TLS 1.1 for probably 99% of .NET apps.

I can personally verify this is an issue since we've run into this exact same problem in a non authorize.net connection and you have to set the flags.  Here is another SO article to support:

http://stackoverflow.com/questions/28286086/default-securityprotocol-in-net-4-5

[Lilith]

@npiasecki @mikeada Thank you both for your feedback, and for the excellent point.

When that particular clause was added, it was because there was concern that the API Best Practices was very abstract, and it was hoped that adding that clause about .NET 4.5 would help provide a concrete example useful for developers. But your point is very valid, and we'll take that into consideration when making updates, prior to the final version.

[Lilith]

I've updated practice #3 with these specifics:

Note that you may need to make code changes to enable security features of the new security patches. For example, in .NET 4.5, TLS 1.2 is available by default. Upgrading to .NET 4.5, and adding “SecurityProtocolType.Tls12” to the System.Net.ServicePointManager.SecurityProtocol property, should provide your solution with support for TLS 1.2. Please consult your platform and framework documentation for more details. 

Thanks again for the feedback--and please let us know if you have any more comments or suggestions.

[mikeada]

Much better, thank you, that will hopefully save a lot of people some headaches.  It's not a well documented problem and Microsoft should probably make it the default IMHO.

[vantamvtf]

Dear,

I'm following this security update for our Authorize.Net integration, we're using ASP Classic to submit the service post_url = https://secure2.authorize.net/gateway/transact.dll as below:

                   Set objRequest = Server.CreateObject("MSXML2.ServerXMLHTTP")
                   objRequest.open "POST", post_url, false
                   objRequest.send post_string

I'm not clear too much about #3, #4, #5 in this article:

#3: Our OS is Window 2012 R2 , when we try to submit to Authorize test environment then it works

https://test.authorize.net/gateway/transact.dll

So do we need specify the security protocol like .Net in ASP? 

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 , if so can you provide the option in ASP?

#4: Our checkout feature process payment as above post, with type are CAPTURE_ONLY, CREDIT and VOID payment, that is called our production environment handles payment data? and do we need a DMZ?

#5: "Specifically, you must not count HTTP header lines to determine where the API response begins, as HTTP headers are subject to change without prior notice."-> sorry I'm not clear this too, with our above progress, what we need to update?

Thank you!

[Lilith]

Before I respond, I should make clear this is an API Best Practices document, not an API Requirements doc. While there are strong statements in this document, emphasized by "must" and "must not," it does not presume to cover every situation, and there may be situations when your solution cannot perfectly adhere to these practices.

Regarding your first question re: Practice #3 -- I'll need to do more research into this, as I am not an expert at ASP Classic. But I am somewhat dubious that ASP Classic allows for support of TLS 1.1 or TLS 1.2. Do any forum readers have better information at hand?

Please note that test.authorize.net currently accepts TLS 1.0, 1.1, and 1.2 connections, which means your solution could be using TLS 1.0. We are discussing when to disable TLS 1.0 in Sandbox and will have an announcement date at a later time.

Re: Practice #4 -- DMZs are required if you are handling payment information and storing it, whether in a temporary variable or a permanent database record. They're recommended if you're storing personally identifying information such as people's names, addresses, email addresses, phone numbers, etc. If you aren't storing any such information, there's no need for you to have a DMZ.

Re: Practice #5 -- Some create their own HTTP parsers in the code and make assumptions about how long, or how large, our HTTP headers are. If we make changes to the HTTP headers, their solutions break. If you are using a parser that's baked into your coding framework, there's a good chance that it properly handles headers by looking for the newline. And in that case, you don't have to do a thing differently.

[vantamvtf]

Dear, thank you a lot for your response, it's helpful for me, our system is already enabled TLS1.2 and disabled early TLS.

[ericwnyc]

I think our solution satisfies the TLS 1.2 and cipher requirements.

Operative word here is "think". It is a little scary that we don't know for sure.

Is there a test url we can try a simple post-response to make sure our solution satisfies the new cipher requirements before they go live?

Thank you for your attention,

Eric