Integration and Testing

[pull-tom]

Do we have any more information as to when Authorize.Net will remove support for earlier versions of TLS?

I'm responsible for maintaining an old website that relies on one of these earlier versions and I need to plan out exactly when to perform the site upgrade to support 1.2. 

It's been 10 months since we've heard anything!

[RichardH Administrator]

Hello @pull-tom

A deadline for moving to TLS 1.2 is not yet finalized, but we do encourage you to begin migration now rather than waiting until the deadline approaches.  We do support TLS 1.2 today.

Richard

[F-Mcfaddin]

Richard,

We've been running into issues where inbound calls from authorize.net only support TLS1.0. We were under the assumption, due to the claim that authorize.net supports TLS 1.2, that traffic would be sent using it.

A packet trace shows authorize.net submits a 187 Client Hello with TLS 1.0 as the supported protocol in the handshake.

How can we receive traffic from authorize.net as TLS 1.2?

Edit: We are utilizing web hooks. The "call" I'm referring to is the POST which authorize.net sends once a payment has been submitted.

[Lilith Administrator]

@F-Mcfaddin -- we just ran a Webhooks test using Runscope, and the result we got back was submitted to Runscope via TLS 1.2.

We have an internal ticket open, but we need for you to confirm if all your Webhooks are using TLS 1.0. We also need our IP addresses, unmasked, so we can identify the origin, should it appear that only one IP address is failing to use TLS 1.2.

Also, could you confirm that you can receive TLS 1.2 traffic from any other source, please?

[F-Mcfaddin]

Hi Lilith,

Thanks for the reply! The masked IP address is my internal IP. The authorize.net IP  that I'm receiving traffic from (TLS 1.0) for this test was 198.241.207.38. My public IP that authorize.net is sending traffic to is 4.35.254.159.

As you can see in the screenshot in my last reply, the handshake from authorize.net (198.241.207.38) is offering TLS 1.0 (which we don't support), so the connection gets dropped.

Here is a screenshot of my mobile phone accessing the same site which authorize.net is attempting to communicate with. The hello lists TLS 1.2:

I have confirmed that when my client is fowarded to authorize.net for payment, the connection is TLS 1.2, but after payment is completed and authorize.net attempts to send transaction info, it's using TLS 1.0.

[Lilith Administrator]

@F-Mcfaddin That suggests there's a problem during TLS negotiation, that causes TLS to downgrade from version 1.2 (which we internally confirmed is the default, in addition to the Runscope test) to version 1.0.

May I have the URLs for your Webhooks, please? I'd like to check the certificate setup and TLS configuration remotely, using SSL Labs if possible, and compare that to our own configuration. That might shed light into why the connection is downgrading.

[F-Mcfaddin]

Hi Lilith,

In my packet traces (the screenshots I've been including in my posts), authorize.net is specifying TLS 1.0 in the beginning of the handshake process; my server, on the otherhand is specifying TLS 1.2 in its response.

I would be open to sharing these full packet traces, and the information you requested in a more private setting. Can someone email me or is there another way to open a support case? (Which I have done, but then was subsequently closed due to this forum thread).

[RichardH Administrator]

Hello @F-Mcfaddin

You can send details to developer@authorize.net and they will be routed appropriately.

Richard

[Lilith Administrator]

@F-Mcfaddin -- thanks, and as Richard said, you can send the PCAP files to developer@authorize.net.

But did you confirm that other services can connect to your servers using TLS 1.2? To be clear, I'm not just talking about a browser test -- I mean an HTTP POST to the server you're hosting your Webhooks URLs on.

Since our internal investigation points at TLS 1.2 being the default, I just wanted to positively rule out there being any issue between what your server supports and what we support on the Webhooks originating servers.

If your servers and ours both support TLS 1.2, but don't agree on TLS 1.2 compatible ciphers, the connection may downgrade in the process of finding a cipher both our servers can agree to. So it would be helpful to know that others' inbound connections to that particular server, are successfully using TLS 1.2.

Also, since ciphers are an important factor here, can we get an SSL Labs report of your Webhooks server's cipher support and other TLS features, please? Alternately, a list of your Webhooks URLs would be appreciated, so we can perform our own discovery. Thanks!