Following the discovery of a number of severe attacks against the SSL/TLS protocol in recent years, fresher and safer versions of the protocol, such as TLS 1.1 and TLS 1.2, are quickly gaining popularity and becoming a new de facto standard across the internet. More importantly, these two most recent versions are set to become a de jure standard for the vast majority of network environments fairly shortly. As per PCI DSS version 3.1, “SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016.”

This means that effective July 2016 most implementations using SSL/TLS versions preceding 1.1 and 1.2 will not be considered secure (technically, from a compliance point of view, as they haven’t been considered as such by the InfoSec community for several years already). The first half of 2016 has been pronounced as a transitional period for users to migrate their environments to newer protocols. We are therefore expecting that by the end of June 2016 there will not be too many systems able to communicate using SSL 2.0, SSL 3.0, and TLS 1.0. Any implementation trying to use an earlier SSL/TLS version to connect to an upgraded system will most likely fail, as there is no version fallback mechanism assumed for security reasons.

Unfortunately, this could be bad news for IT solution vendors. While older systems such as Windows XP or Windows Vista have now been abandoned by Microsoft and are not officially supported any more, there exist plenty of environments where these systems are being used. While powerful, fairly reliable, and unpretentious of resources, the problem with these operating systems is that due to their solid age they do not support TLS 1.1 and TLS 1.2 internally -- these protocols did not exist at the time they were released. Worsening the situation is the fact that a number of third-party applications and OS components -- such as Internet Explorer, IIS, or the Active Directory browser -- rely on the Windows WinInet and SChannel API for their SSL/TLS connectivity and as such are restricted to the security capabilities the API provides.

Things are not any better for .NET Framework users. The System.Net.Security.SSLStream component (and all higher level components that use it internally, such as HttpWebRequest and SmtpClient) internally rely on the same unmanaged SChannel API, making all applications built around those components subject to the same TLS limitations. What this means is that a large number of applications will become noncompliant and noncompatible after June 30, 2016. What is much worse, there is no easy mechanism to extend their compatibility, for the limitations are set deep in the operating system's internal modules and -- due to terminated platform support -- can never be removed.

This poses a challenge for a plethora of organizations of different scales who are satisfied with the overall functionality offered in Windows Vista, Windows XP, and earlier revisions of Windows Server 2008 and use those operating systems extensively. The need to comply with the recent changes in PCI DSS and other recent security policies puts before them the urgent need of upgrading a certain share -- if not the whole -- of their fleet of XP and Vista machines. Quite often this implies the need to upgrade hardware too, due to the much greedier demands of the newer operating systems.

SecureBlackbox can offer a solution for software developers and integrators affected by this compliance issue. For more than ten years we have been offering a fast, stable and reliable collection of TLS-capable software components. Based on our own, native implementation of TLS, the components do not depend on OS internals, so you can enjoy the benefits of TLS 1.2 on such systems as Windows Vista and Windows XP. Our components provide support for TLS itself as well as for a number of secured application layer protocols, such as HTTP(S), FTP(S), SMTP(S), and POP3(S). The components are available for a wide range wide range of development environments and target platforms, from .NET framework to Visual C++ to Delphi, and feature a standard, easy-to-use interface. Using SecureBlackbox as your TLS solution, you can extend the life of discontinued yet still viable systems and avoid any substantial and expensive changes to your infrastructure.

The requirement to provide full compatibility for up-to-date TLS 1.1 and TLS 1.2 versions by mid 2016 took many software developers and IT staff by surprise. You can find an up-to-date and secure replacement for obsolete built-in SSL with the SecureBlackbox components.