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!

[Lilith]

@skyetech That isn't surprising. Windows uses Secure Channel (AKA SChannel) for negotiating SSL/TLS with browsers and other services not going directly through IIS. The versions of SChannel used in Server 2003/XP cap at TLS 1.0, with older and weaker ciphers.

Chrome uses its own TLS negotiation setup, with its own cipher suites and certificate store. It also auto-updates, making it more resiliant to the sorts of issues legacy IE users face.

[dlewis9]

So is sandbox currently RC4 disabled?  Just making sure it was not delayed again.

[RichardH]

@dlewis9

Yes, RC4 is disabled in the sandbox.

Richard

[gcgala2]

Can you confirm that RC4 is even disabled in the sandbox for users of AIM, using this endpoint URL(?):

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

Many thanks.

[RichardH]

@gcgala2

All of our sandbox endpoints no longer support RC4.  You can confirm this using Qualys SSL Labs tool:

https://www.ssllabs.com/ssltest/analyze.html?d=test.authorize.net

Richard

[michaelrepucci]

If our application server (Glassfish 4.0) is running on JDK 8, and we're using the Authorize.NET Java SDK, can we assume that TLS 1.2 is being used? I can't seem to find any object in the Authorize.NET library that explicitly sets the outbound TLS protocol version. Our application server is configured to use TLS 1.2 for inbound requests. Is that enough?

[ShilpaAutho]

We are using .net framework 4.0 in our project. How to do a workaround for this then ?

I suppose there are 2 ways:

1) Using existing project with .net framework(4.0). Installing .net framework 4.5 in my machine. Changing the code as ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

2) Upgrading project to .net framework 4.5.

Can we use the 1st option for time being ?

Kindly suggest.