TLS Server 2003

[jlambert]

I'm looking for some advice on the TLS 1.0 issue. I'm currenlty running Windows Server 2003 (don't ask) and can't see moving off of it completely by the new Sept 2017 Authorize.Net deadline for TLS 1.0. 

What I need direction on is utilizing an Authorize.net hosted payment form. If I do this, does this get me around the TLS 1.0 issue for now? What Authnet solution would be best? I know there's a simple payment form, but I think I need something just a little more customizable. Currently I believe we are using the API (but I don't know much about it).

Thanks in advance!

[Lilith]

There is no support for TLS 1.2 under Windows Server 2003. The earliest version of Windows Server that supports TLS 1.2, is 2008 R2. Also, Microsoft stopped offering support for Server 2003 in July 2015. Unsupported code is usually seen as a PCI DSS violation in its own right, since there are no new patches for emerging security issues.

You would still need TLS 1.2 to utilize any Authorize.Net service, since you'd still have to share sensitive data (your account credentials, for example). Without support for TLS 1.2, you wouldn't be able to utilize our legacy (and deprecated, and therefore not recommended) SIM payment form, let alone the modern Accept Hosted option or our other API options.

Furthermore, most payment gateways are moving ahead with removing TLS 1.0 and 1.1 -- PayPal will be doing so in June 2017, and Stripe had a particularly aggressive schedule for removing TLS 1.0/1.1 support, and do not offer support for anything less than TLS 1.2 today.

The best advice I can give, if you can't completely upgrade your infrastructure, would be to set up an independent server or proxy that can handle TLS 1.2, for your API connections, and then upgrade the back end infrastructure to properly support TLS 1.2.

[jlambert]

Thank you for the information. The secondary (proxy) server is another option being discussed and it sounds like that might be the only way to go at this point.

[NexusSoftware]

If the application uses the library provided by the operating system(schannel.dll), then Windows 2003 supports only: SSL 2.0, SSL 3.0 and TLS 1.0. However if you build your application to use another library, it could support TLS 1.2.

There is also a way to modify the registry settings by adding a specific list of cyphers to [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL] and enabling them in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders], as well as modifying a few other settings there, which will enable TLS 1.2, but still the encryption capabilities of Windows 2003 by itself is limited.

Another way is to run an embedded server like WolfSSL.

Though for the price of servers nowadays, you probably would be better off with a small Windows 2012 or better yet Nginx with .Net Core solely for your payment processing functions.

[Lilith]

@NexusSoftware -- Thank you for providing more options. Certainly, using something like WolfSSL, or cURL with OpenSSL, are options if the only concern is that the box itself supports TLS 1.2.

That said, it would still be ill-advised to use a Server 2003 box to initiate the TLS connection. As I mentioned, PCI DSS discourages unsupported software, so I would imagine any merchants using Server 2003 would be at risk of failing a compliance scan. For that reason alone, I can't recommend either the Registry changes you suggested, nor using an alternative to SChannel.

I definitely agree that, given the current pricing for servers, it'd be cheaper to host the payment processing on a separate, supported platform.