I think that for the rest of this year and early next year we are going to see quite a few challenges that will cause shifts in our platforms and user computing base.  Some of these, such as the end of support for Windows XP and Server 2003, we have seen coming for quite a while and knew we had a deadline.  Others were more  along the lines of ‘yeah, thats bad and we will fix it some day’.  Over the last two years these slow burning ‘some day’ issues have been fully ignited due to the Snowden releases and several SSL/TLS vulnerabilities turning the theoretical risk into practical and operational problems.

I don’t plan on going into too much detail here but what I want to do is to provide a list of  some challenges that I think many of us will be facing over the next 12 months or so.

In no particular order:

Windows XP end of support

Extended support for Windows XP ended on April 8, 2014 but this IT zombie will be around years after it is dead.  I have a post dedicated to its particular challenges here that you can reference for details.

Windows Server 2003 end of support

Extended support for Windows Server 2003 ends in July 2015.  After that date no support, paid or otherwise, will be available from Microsoft.  Also, they will not provide patches to address newly discovered vulnerabilities.  The TLS situation is slightly better than XP as Microsoft added support for 2 AES cipher suites to the OS last year. If you are running Server 2003 in your environment I recommend that you investigate upgrading or replacing the OS as soon as you can.

Change in support for Microsoft Internet Explorer

In August 2014 Microsoft announced a change that limited which versions of Internet Explorer it supported.  After January 12, 2016 only the most recent version of Internet Explorer available for a supported operating system will receive technical support and security updates.  Here is the current list:

Windows Platform	Internet Explorer Version
Windows Vista SP2	Internet Explorer 9
Windows Server 2008 SP2	Internet Explorer 9
Windows 7 SP1	Internet Explorer 11
Windows Server 2008 R2 SP1	Internet Explorer 11
Windows 8.1	Internet Explorer 11
Windows Server 2012	Internet Explorer 10
Windows Server 2012 R2	Internet Explorer 11

From a security standpoint this means that we must upgrade to the latest browser on the OS in order to have vulnerabilities addressed.  This will likely be a mandatory upgrade in high security or regulated environments.  This will likely have an impact on older applications that don’t play well with IE 11 or that expect to be able to launch attachments without user prompts.  If you haven’t already done so I recommend that you start testing your web applications and working with your vendors to ensure that their products work with the appropriate browser version.

SHA1 signed certificate deprecation

Over the last couple of years Certificate Authorities (CA) and browser vendors have made statements indicating that they will be removing support for SHA1 signed certificates due to weakness with the hashing algorithm.  Many of these efforts are being handled in phases. The impacts of this are already being felt and will continue to grow throughout 2015 and 2016. Ivan Ristić has what I think is the best article  on the topic, but here are some of the highlights:

• The most popular browsers will consider SHA1 certificates that expire after 12/31/2016 as invalid and generate an warning to the user.

• Chrome also will be generating additional warnings for SHA1 certificates that expire during 2016.

• Microsoft’s SChannel implementation that handles SSL/TLS on Windows will mark all SHA1 certificates as invalid on January 1, 2017.  This will affect all software that leverages SChannel on Windows.

• Many CAs will not issue new SHA1 signed certificates unless you go through a special process.

• Many CAs will allow valid SHA1 certificates to be reissued as SHA256 at no cost.

• Any client software that uses SSL/TLS needs to be checked to ensure support for SHA256.  Most software released in the last couple of years should be fine, but be aware of corner cases. Citrix Receiver for Linux only added support last year in version 13.1.

RC4 deprecation

There have been known and suspected weaknesses with the RC4 encryption algorithm for some time.  Security experts and vendors have been recommending that, if it is used at all, RC4 only be used as a last resort for compatibility. Vulnerability scanners and TLS grading sites have been warning or penalizing the grades for sites that support it. In Feb 2015 CloudFlare announced that they had disabled RC4 for their properties and hosted services. I expect that other organizations will follow suit as they deem appropriate.  Most products support better algorithms than RC4 but some may be configured in a way that prevent their use.  Also, older proxies or other network devices may have similar problems.  You can test the effective crypto of your browser using pages by SSL Labs or HowsMySSL.com .

SSL v3 deprecation

Many have wanted to kill the use of  SSL v3 for some time.  This has been held back by the need for client compatibility (IE 6.0 on XP didn’t have it enabled by default) and inconsistent TLS 1.0 support.  The release of the POODLE vulnerability last year has pushed many security experts to call for an end to SSL v3 and many organizations to start disabling it.  Some of the most well known public services to have disabled SSL v3 are Facebook, Amazon, and CloudFlare. End users can expect more services to disable SSL v3 though I would not expect any negative impacts. Mozilla has disabled SSL v3 by default in Firefox 34 released on Nov 24, 2014. Google has also disabled SSL v3 in Chrome 40 and later. Service providers and those in regulated environments can expect pressure to disable SSL v3 on servers.

TLS implementation flux

It has been my experience that vendors are implementing TLS 1.1 and 1.2 but are not doing so consistently.  I’ve seen vendors implement TLS 1.2 but not any of the cipher suites that make it useful.  Some are implementing it on one version/edition of their product and not others.  An example of this is Citrix Netscalers provide TLS 1.1 and 1.2 on their hardware platforms (SRX and MPX) but not on the VPX virtual appliance which shares the same codebase.  F5’s BIG-IP platforms support TLS 1.2 since at least 11.0 but  no ECDHE until 11.4,  and no AES GCM or no ECDSA until 11.5 . If you require TLS 1.2, AES GCM, ECDHE, or ECDSA I strongly suggest that you verify that the products you are using support it on the exact model and version that you intend to use.  I also recommend that you test and verify the desired configuration to ensure that everything works as it should.

Update 2015.04.01 – The block above incorrectly stated that the F5 BIG-IP platform did not support AES GCM until 11.6.  This was incorrect as it was added in 11.5

Flotsam and jetsam

In any organization of significant size there will be older systems that are forgotten or haven’t been upgraded due to lack of importance or the difficulty of doing so.  These systems are going to get progressively harder to manage as browsers, libraries, and operating systems no longer support the protocols, crypto, and tools needed to do so. The effort involved with identifying these systems and either upgrading or replacing them will likely be much lower now than it will be next year.

In summary, the term ‘old and busted’ applied to legacy software and crypto will soon be more literal than figurative.  Many of the changes will be out of your hands as third parties remove unsafe crypto.  Planning and effort now will reduce effort, time, and potentially outages in the future.

Good luck!

– Tom