(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

August 9, 2017 3

Can Security Improvements Have a Negative Effect?

in Everything Encryption

While Debian looks forward, Microsoft looks back.

In many areas of internet networking, but especially within the Web PKI and world of SSL/TLS, we live with the decisions of the past. Weak cryptography, bad protocol designs, and non-standard software haunt us like some of the questionable decisions we made back in college.

The basic cycle looks like this: An operating system or library is released. Organizations and businesses integrate and rely on that software. And then the ecosystem deals with that software’s shortcomings for years and years and years.

As the internet grows in size and importance, we have tried to make smarter decisions to avoid – or at least shorten – that cycle.

Recently, two operating systems made updates that reflect two different approaches to ecosystem health:

Debian pushed a change to its pre-release build that would have it only support TLS 1.2; and Microsoft added TLS 1.2 support to Windows Server 2008.

These two choices represent opposite perspectives – one looking forward, the other looking back.

Debian released a new version of the OpenSSL library to its unstable build – a development version containing the latest cutting edge features; and supporting only TLS 1.2 is certainly on that edge. That is a configuration rarely seen today – only Mozilla’s “Modern” configuration settings recommend solely using TLS 1.2.

Kurt Roeckx, a long-time Debian developer who maintains its OpenSSL library, wrote “I hope that by the time Buster releases the support for TLS 1.2 will be high enough that I don’t need to enable [TLS 1.0 & 1.1] again.”

Buster is the codename for Debian 10, which is the next major release of the Linux distribution. There is no announced release date, but based on past releases, it is more than a year away.

For now, Roeckx does not have much sympathy for those that need older versions, writing to those that might be affected: “I strongly suggest …you add support for [TLS 1.2], or get the other side to add support for it.”

By the time Buster releases, it may no longer be seen as a ‘daring’ move to drop support for all SSL/TLS versions before TLS 1.2. However, those familiar with SSL/TLS and Web PKI know that we love to hang on to features for as long as possible.

Case in point, Microsoft has just  added TLS 1.1 & TLS 1.2 support to its aging Windows Server 2008 platform.

At face value, adding support for stronger versions of TLS seems like a good thing. However, when we look at Server 2008’s other TLS capabilities, the potential downsides become more apparent:

• No AES GCM support
• No AEAD ciphers
• No SNI (Server Name Indication) support
• No OCSP Stapling support

That is not a very appealing HTTPS server. Probably not one you would want to use today, and definitely not one you will want to use three years from now.

Windows Server 2008 (which uses IIS 7) is still in its Extended Support phase until 2020. But why add TLS 1.2 support now?

Well, starting June 2018, you will have to support TLS 1.1 or higher to be PCI compliant. This update will allow Windows Server 2008 to continue to be used in systems that process, store, or transmit cardholder data.

Microsoft does not mention PCI in either of their blog posts about adding TLS 1.2. It says it wants to remove hurdles to “deprecating older security protocols” and is committed to “best-in-class encryption.”

But if better security was really the goal, why did Microsoft neglect to add other modern capabilities? To be fair, Windows Server 2008’s TLS support is not atrocious. It does at least have PFS (Perfect Forward Secrecy) ciphers thanks to ECDHE support.

At some point, polishing up an aging system can actually be worse for security and the ecosystem as it gives businesses and users excuses to hold on to systems that should really be replaced or upgraded.

That’s part of the reason that Chrome removed the entire class of Diffie-Hellman ciphers last year. While it could have easily left support for stronger 2048-bit parameters, it was a cleaner and safer solution to just do away with them altogether.

Debian’s “upgrade or die” decision on TLS 1.2 may not end up making it to release (some are already skeptical), but it is nice to see an attempt at forward-thinking. Meanwhile, the question remains if adding TLS 1.1 and 1.2 support in Server 2008 will be a positive thing for the ecosystem, or if it’s just extending the long-tail of legacy support even further.

• #Debian
• #Google Chrome
• #Microsoft
• #SSL/TLS
• #TLS 1.3