Following a number of severe attacks against SSL/TLS protocol discovered 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 a 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 30th June, 2016.” (“Migrating from SSL and early TLS”, version 1.0, April 2015, PCI Security Standards Council).
This means that effective July 2016 most implementations using SSL/TLS versions preceding 1.1 and 1.2 will not be considered secure anymore (well, from compliance point of view – as they haven’t been considered as such by InfoSec community for good couple of years already). The first half of year 2016 is pronounced as ‘transitional period’, for the users to migrate their environments to newer protocols. We are therefore expecting that by the end of June 2016 there will be not too many systems able to talk 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 news isn’t that good for IT solution vendors. While older systems such as Windows XP or Windows Vista have now been abandoned by Microsoft and not officially supported any more, there exist plenty of environments where those resource-unpretentious, powerful and fairly reliable systems are still being heavily used. The problem with those operating systems is that due to their solid age they don’t support TLS 1.1 and TLS 1.2 internally – just because those protocols didn’t exist at the time when they were released. The things are worsened by the fact that a big deal of third-party applications and OS components – such as Internet Explorer, IIS or Active Directory browser – rely on Windows WinInet and SChannel API for their SSL/TLS connectivity, and as such are restricted with the security capabilities the API provides.
The things aren’t any better for .NET framework users. System.Net.Security.SSLStream component (and all higher level components which use it internally, such as HttpWebRequest or 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 non-compliant and non-compatible ‘pumpkins’ when the clock strikes twelve on 30 June 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 big challenge. A plethora of organisations of different scales are quite happy with 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 them before 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 the hardware part too, due to much greedier demands of the newer operating systems. Happily, here at EldoS we 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, Windows XP and even Windows Mobile 2003 (anyone remembers that?) Our components provide support for TLS itself as well as for securized application layer protocols, such as HTTP(S), FTP(S), SMTP(S) and POP3(S), are available for a wide range of development environments and target platforms, from .NET framework to Visual C++ to Delphi, and are really easy to integrate and use. By switching to EldoS’ TLS solution in your software product you can extend the useful life of the honorable but discontinued systems and avoid any substantial and expensive changes to your infrastructure. You can read more about the product we offer here
* * *
The requirement to provide full compatibility for up-to-date TLS 1.1 and TLS 1.2 versions by mid 2016 took a big crowd of software developers and IT people by surprise. Here at EldoS we are delighted to be able to help those badly affected by offering an inexpensive, high quality and supported replacement for an obsolete built-in SSL support in the systems no longer supported by their vendor. There’s still time to switch your solution from an outdated and non-compliant technology to the up-to-date and secure implementation of the TLS suite from EldoS, and our engineers will do their best to assist you in this.