Authorize.net is disabling support for TLS 1.0 and 1.1 in production as of September 18, 2017. As of that date, they will only support TLS 1.2. You can read more here:
http://app.payment.authorize.net/e/es.aspx?s=986383348&e=1411090
I have a customer using a .NET integration with Authorize.net, so I reviewed my code and did some research on which protocols .NET supports and uses.
I reviewed my code and confirmed that I was not explicitly setting the TLS protocol version. So I researched which versions of TLS were supported by which .NET versions, and how the version was chosen.
After reading a few posts on StackOverflow, I confirmed that .NET 4.5 does support TLS 1.2. So that was good news. After reading a few more posts, my understanding was that .NET auto negotiates the protocol with the server, so if Authorize.net requires TLS 1.2, I thought that my .NET app should work fine.
So I tested against the Authorize.net developer sandbox, which has already been set to require TLS 1.2, and to my surprise, I received a connection error. I researched the error and confirmed that it was due to the TLS 1.2 requirement. But if .NET 4.5 supports TLS 1.2 and is able to negotiate the protocol version, why would my connection fail?
My only guess is that Authorize.net, in addition to requiring TLS 1.2, Authorize.net have configured their systems to detect protocol negotiation requests and deny those connections. My assumption is that this may be a measure to prevent surreptitious protocol downgrades, such as the POODLE vulnerability, which makes sense.
So I updated my application to include the following line of code:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
(You will need a "using System.Net" reference as well in your class)
This explicitly tells System.Net to only use TLS 1.2. After I added this line, my connections to the Authorize.net developer sandbox started working again.
Given this finding, I will need to prepare a new release and will have to work with the customer to deploy the new application before September 2017.
And one other small downside to this approach is that my application is now hard coded to TLS 1.2. But in practical terms, I am not concerned about this, as TLS 1.2 is the latest version available in .NET 4.5. If a new version of TLS is released, Authorize.net will probably require that specific protocol, and I'll need to update the .NET version of my application anyway, so I'll have to prepare a new release regardless.
UPDATE: And coincidentally, one after hour posting this article, I saw a discussion about TLS v1.3, which is apparently in the works:
https://github.com/tlswg/tls13-spec/issues/1001
So I learned a few things from this process, and fortunately the fix turned out to be very easy.
No comments:
Post a Comment