Jump to content
Sign in to follow this  

PCI Compliance and Deprecation of SSL/TLS versions

Recommended Posts


1 - I was wondering, has / does your company plan to deprecate all versions of SSL and the earlier version(s) of TLS on your customer accessible servers, ie the REST servers.
Reference this article:  https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

The reason I ask is, that broker server I/O _may_ be considered "financially affecting" and your Compliance / IT department _may_ be considering this deprecation.  This would be a good move, not a bad one.  However, this will impact anyone writing code in (in at least) a windows environment (specifically the dotnet folks).   The reason is that when "WebRequests" are made to your REST servers using the dotnet framework, the underlying framework algorithm for negotiating an "agreed upon" secure channel, can / does fail if SSL and earlier versions of TLS are missing on either the customers server and/or your servers.

In at least the dotnet development environment, this one line of code would have to be added to the WebRequest subroutine just BEFORE the URL Request object is created:
'the following forces TLS 1.2 to be used...
ServicePointManager.SecurityProtocol = 3072 'This line forces TLS 1.2 to be used.

This would have the effect of bypassing the secure channel negotiation, and use TLS 1.2 straight away, thus sidestepping any potential negotiation issues.

I have already seen this issue at some other broker REST servers and I had to implement the above to ensure the channel would be negotiated.

2 - Do your REST servers currently support TLS 1.2?

As always, thanks for your answers.

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this