Loading...
Just before 7AM EDT on Sunday July 1 2018, TSYS permanently disabled TLS 1.0 in both of our data centers, per PCI's industry-wide mandate. If you attempt to process a transaction using TLS 1.0 through any of the TSYS-offered API's, the request will fail and your transaction will not be processed. Additionally, attempting to access any Merchant or Partner portal from a workstation which does not support or have TLS 1.2 enabled, will result in failure of the page loading.
Please refer to the below topics for additional information on why this change has been implemented, what systems are impacted and suggestions for configuring and resolving issues which may be related to this change.
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as "SSL", are cryptographic protocols that provide communications security over a computer network.
In 2014, the US National Institute of Standards and Technology (NIST) declared TLS 1.0 to be unacceptably weak and unsafe cryptographic protocol. Accordingly, the PCI SSC has mandated that TLS 1.0 must be disabled by June 30, 2018 (per PCI 3.1 and PCI 3.2). All payment application providers are required to update to (at least) TLS 1.1 - if not TLS 1.2 - by this deadline.
The TSYS gateway has supported TLS 1.1 and 1.2 since at least mid-2014. In accordance with the PCI SSC's mandate, on July 1, 2018, TSYS will be disabling support for TLS 1.0 in all of its products, including (but not limited to) Genius, Transport.Web, MerchantWare, and its portals.
We've seen some payments providers take the stance that they will only support TLS 1.2. Our present position is to support both TLS 1.1 and TLS 1.2, while strongly encouraging its merchants and ISVs to support TLS 1.2. Should NIST or PCI deem TLS 1.1 to be an "unacceptably weak and unsafe cryptographic protocol" as TLS 1.0 was, we will of course take appropriate action to discontinue supporting that protocol.
As a pragmatic matter, TLS 1.1 and 1.2 were rolled out in all major operating systems (eg. Windows 7), frameworks/runtimes (eg. Java 7), and libraries (eg. OpenSSL) simultaneously. Combined with the fact that these protocols are designed to auto-negotiate the strongest possible encryption possible by default, in practice, this has resulted in very little TLS 1.1 adoption in the marketplace. Indeed, TLS 1.1's usage on our payment gateway is presently a rounding error (< 1%), compared to TLS 1.0 (roughly 60% as of 2017Q2) and TLS 1.2 (roughly 40%), andbecause of this, we expect that after the July 1, 2018 deadline, over 99% of our gateway's traffic will be secured using TLS 1.2.
TSYS is also eagerly monitoring TLS 1.3's status, as it is quickly moving from being a working draft to being an official RFC, in our desire to provide the utmost security for its merchants and partners' payment transactions.
Some payments providers (eg. Elavon) and stored value/gift card providers are discontinuing support for TLS 1.0 earlier than the PCI mandated mid-2018 deadline. TSYS does not expect this to present any challenges for its merchants or ISVs. TSYS has made preparations in advance of these cut-over dates, and already uses TLS 1.2 when communicating with all of its payments partners. Your terminals and points of sale can continue to connect to TSYS using TLS 1.0/1.1/1.2 until mid-2018. Behind the scenes, our payment gateway makes a connection using TLS 1.2 to your acquiring bank (eg. First Data, Elavon, Chase, etc...), so no disruptions to your processing are expected due to these cut-overs. By using our gateway, merchants and ISVs are insulated from any early TLS 1.0 sunsetting dates done by acquirers.
We do want to note that some of these payments providers also offer web browser based portals in which merchants can review their transactions. These portals are not controlled by TSYS, and if merchants wish to continue to use these portals, their browsers/operating systems must be updated as per below to support TLS 1.1 (or in many cases, TLS 1.2) on the schedule dictated by their respective payments providers.
Our products are largely provided as a collection of HTTPS based web services. All communications between your POS and our payment gateway are thus secured using TLS. If your POS is deployed on a system that doesn't support newer TLS versions (eg. any version of Windows before Windows 7), you may be unable to make payments using our solutions come July 1, 2018.
Fifteen years ago, SSL v3.0 was superseded by TLS v1.0, which has since been superseded by TLS v1.1 and v1.2. To date, SSL and early TLS no longer meet minimum security standards due to security vulnerabilities in the protocol for which there are no fixes. It is critically important that entities upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.
Please see the PCI SSC Guide on Migrating from SSL and Early TLS.
Our primary online shopping solutions, Checkout and TransportWeb, both communicate with our servers using HTTPs. If your users are using older browsers or operating systems (eg. Windows before Windows 7), they may be unable to make payments using our solutions come July 1, 2018.
If your web servers communicate with our payment gateway, these will also need to use TLS 1.1/1.2.
A tool like Wireshark can help. See https://wiki.wireshark.org/SSL
You (or your merchants) are more likely to be affected if your POS or server:
You (or your merchants) are less likely to be affected if your POS:
Absolutely. We have a lab available for partner testing that only requires you to edit your point of sale's "hosts file" or DNS within your control (eg. a wireless router within your lab). The lab's IP is 209.133.97.131. You'll need to create an entry in your hosts file for transport.merchantware.net:
This lab points at our Chicago production environment, and is not subject to any SLAs, including uptime. Please reach out to our Integrations Team via integrations@cayan.com for assistance.
While TSYS is committed to supporting both TLS 1.1 and TLS 1.2 in our production environment come July 1 2018, our TLS lab will only support TLS 1.2, and we will be working with our ISVs to ensure that they support TLS 1.2 as they validate their points of sale and shopping carts in our lab. This will help ensure that our merchants will not experience any issues if/when TLS 1.1 is found to be cryptographically weak, and the protocol must be sunset. In practice, less than 1% of our traffic is secured using TLS 1.1 today, so we do not anticipate this more stringent requirement being a problem for our ISVs.
TSYS recommends you test against the TLS lab from all operating systems that are supported by your customer base if possible. TSYS also recommends you test against the TLS lab while using all APIs you are certified for or plan to certify.
The Microsoft Security Team has written several articles on the state of TLS 1.2 support at Microsoft.
The below table is a quick reference guide regarding which versions of Windows support TLS 1.1 and 1.2.
Please note that if you are using Windows 7, Windows Server 2008 R2, or Windows 8, Windows has support for TLS 1.1 and TLS 1.2, but it is disabled by default. These can be changed in a number of ways - the simplest being the "Internet Option" dialog in your Control Panel. One can also push these registry changes to your workstations via Group Policy. Please note that Windows maintains different registry settings for 32 vs. 64 bit programs, and depending on how your POS is implemented, one or both registry settings may need to be updated.
Tools such as IIS Crypto can help enable your IT team enable or disable protocols, ciphers, hashes and key exchange algorithms on Windows Server 2008, 2012 and 2016. It also lets you reorder SSL/TLS cipher suites offered by IIS, implement best practices with a single click, create custom templates and test your website.
On October 5th, Microsoft announced that it has enabled TLS 1.1 and 1.2 support on Windows POSReady 2009. More details, including instructions for applying and enabling TLS 1.2 and 1.2 are available from their Security Team's post Announcing support for TLS 1.1 and TLS 1.2 in XP POSReady 2009.
Below are a number of resources from Microsoft regarding TLS support on Windows
Use the SecurityProtocol property to enable TLS v1.2.
For details on how to use the SecurityProtocol property, visit:
[https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol%28v=vs.110%29.aspx)
[http://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx](http://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype%28v=vs.110%29.aspx)
For example, to force TLS v1.2 in a C# .NET implementation, you would use:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
NOTE: JDK 8 will use TLS v1.2 as default: [https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls](https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls)
For JDK 7, use the SSLContext.getInstance method to enable TLS v1.2.
For details on how to use the SSLContext.getInstance method, visit:
[http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String)](http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance%28java.lang.String%29)[http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String,...](http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance%28java.lang.String,...)[http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext](http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext)For example, to use the default security layer provider to enable TLS v1.2, you would use:
object = SSLContext.getInstance("TLSv1.2");
To force TLS v1.2 while using Oracle’s Sun Java Secure Socket Extension (JSSE), you would use:
object = SSLConnect.getInstance("TLSv1.2", "SunJSEE");
Use the CURLOPT_SSLVERSION option to enable TLS v1.2.
For details on how to use the CURLOPT_SSLVERSION option, visit: [http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html](http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html)
In cURL version 7.34.0 or later, use the following examples to force TLS v1.2:
C/C++/C#:
curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
PHP:
curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
Even if the underlying operating system doesn't support TLS 1.2 (eg. Windows POSReady 2009), there's still hope. There are a number of 3rd party TLS libraries that a POS developer might employ in your solution so that your software can support TLS 1.2, without requiring merchants to go through expensive hardware & operating system upgrades. Using this approach, TSYS was able to make its Store & Forward product support TLS 1.2 on Windows POSReady 2009, with only a few days' effort.
Without making any endorsement or claims of fitness, below are several such libraries that you might consider: