topic Re: Request for Comments: API Best Practices - test url? in Community Feedback

Request for Comments: API Best Practices

Lilith — Fri, 29 Jan 2016 18:51:39 GMT

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

Please post your feedback below. Thanks!

Re: Request for Comments: API Best Practices

npiasecki — Sat, 30 Jan 2016 14:25:18 GMT

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.

Re: Request for Comments: API Best Practices

mikeada — Thu, 18 Feb 2016 21:44:42 GMT

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

Re: Request for Comments: API Best Practices

Lilith — Mon, 22 Feb 2016 18:40:41 GMT

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

Re: Request for Comments: API Best Practices

Lilith — Wed, 24 Feb 2016 21:21:59 GMT

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.

Re: Request for Comments: API Best Practices

mikeada — Tue, 01 Mar 2016 19:39:12 GMT

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.

Re: Request for Comments: API Best Practices

vantamvtf — Sat, 26 Mar 2016 04:00:57 GMT

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!

Re: Request for Comments: API Best Practices

Lilith — Tue, 29 Mar 2016 15:55:16 GMT

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.

Re: Request for Comments: API Best Practices

vantamvtf — Wed, 30 Mar 2016 09:33:31 GMT

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

Re: Request for Comments: API Best Practices - test url?

ericwnyc — Wed, 30 Mar 2016 18:33:19 GMT

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

Re: Request for Comments: API Best Practices - test url?

Lilith — Wed, 30 Mar 2016 22:48:23 GMT

@ericwnyc As mentioned last post, these are not hard requirements. Strong suggestions, certainly -- but we are not mandating any changes at this point. The point of this document is to encourage good API implementations and usage that meet or exceed contemporary standards, and so we strongly recommend using TLS 1.2 and ECDHE ciphers.

That said, our intentions are that any changes to our Production API endpoints along these lines, will be preceded by the same change to Sandbox well in advance, so you can test your integrations.

The next anticipated change in Production along these lines, will be for the sunsetting of RC4 ciphers. We don't have a firm schedule for that as of yet. We do plan on removing RC4 support from Sandbox in the near future, and will have a formal announcement in the Developer Community Blog when we have a date planned.

Re: Request for Comments: API Best Practices - test url?

ericwnyc — Thu, 07 Apr 2016 18:02:57 GMT

Hi Lilith,

I hadn't noticed thatin the announcement. Knowing we will be able to run a test in sandbox before this goes live makes me much more comfortable.

Thanks for the reassurance!

Eric

Re: Request for Comments: API Best Practices - test url?

Lilith — Fri, 08 Apr 2016 14:52:24 GMT

@ericwnyc I should have a new announcement about TLS and the new deadline set by the PCI Security Standards Council, by Monday if not sooner. We already have ECDHE ciphers in Sandbox, and we'll bring up RC4 in another announcement, likely next week.

Re: Request for Comments: API Best Practices

EHill — Thu, 14 Apr 2016 15:57:54 GMT

What is authorize.net deadline for using TLS 1.2 for all transactions? We use TLS 1.1 and have plans to upgrade our aspdotnetstorefront from 9.3 to 9.5 which would support TLS 1.2 but we will not be upgraded by June 30, 2016.

Re: Request for Comments: API Best Practices

Lilith — Fri, 15 Apr 2016 16:13:37 GMT

I apologize for not having the new TLS update out yet.

We're currently rescinding our original early 2017 deadline, and won't be setting a formal deadline until closer to the PCI DSS 2018 deadline.

In the meantime, we're discussing adding resources for testing TLS 1.2 connections, so the formal announcement about the TLS deadline may be delayed until those testing resources are in place.

Re: Request for Comments: API Best Practices

Lilith — Fri, 15 Apr 2016 16:17:17 GMT

@EHill You will have ample time. We originally had a 2017 deadline but have pushed that back to 2018 for the time being.

I anticipate we will have a way for you to test your new TLS 1.2 setup in the next few months -- hopefully even sooner.

That said, we appreciate you updating aspdotnetstorefront as soon as the 9.5 upgrade is available. The security benefits of using TLS 1.2 are significant enough that we don't advise delaying the update, regardless of any deadline we set.

Re: Request for Comments: API Best Practices - test url?

dkaufman — Wed, 20 Apr 2016 14:11:41 GMT

Yes, the link is right there in the article:

"...you can use a site such as https://www.howsmyssl.com/ to connect and validate your cipher list"

ericwnyc wrote:

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?

Re: Request for Comments: API Best Practices - test url?

skyetech — Wed, 20 Apr 2016 16:54:11 GMT

I'm pretty sure https://www.howsmyssl.com/ only tests clients.

Re: Request for Comments: API Best Practices - test url?

Lilith — Thu, 21 Apr 2016 15:24:24 GMT

@skyetech There is an API tab on that site, which explains how you can submit tests directly to their servers, and which would be better suited for API testing in general:

https://www.howsmyssl.com/s/api.html

Also, it's worth noting that, when we're talking about HTTP, whatever creates the initial request, is considered a client, even if it's running on a server.

We're in discussions about how to set up TLS 1.2 testing, and once we have our own URLs for testing purposes, we'll make an announcement.

Re: Request for Comments: API Best Practices - test url?

skyetech — Thu, 21 Apr 2016 16:38:35 GMT

@Lilith wrote:

Also, it's worth noting that, when we're talking about HTTP, whatever creates the initial request, is considered a client, even if it's running on a server.

I'll have to learn more about this.

I ran https://www.howsmyssl.com using Chrome on a Server 2003 box and the result said "Your client doesn't use any cipher suites that are known to be insecure". I didn't think that could be true on Server 2003. If I run it with IE and I get "Your client supports cipher suites that are known to be insecure".