cancel
Showing results for 
Search instead for 
Did you mean: 

Request for Comments: API Best Practices

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

Please post your feedback below. Thanks!

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Lilith
Administrator Administrator
Administrator
26 REPLIES 26

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

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

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

 

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

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

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.

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.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Lilith
Administrator Administrator
Administrator

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

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
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?

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

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

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

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