Excellent TLS Made Easy

Tuesday, March 24, 2015



By: Matt Thomas 

One of the most common findings we discover on assessments is misconfiguration of SSL/TLS implementations. Cryptography is notorious for requiring very specific skills to configure correctly, and on top of that it tends to be a moving target: it seems like every other month there is a new vulnerability specific to SSL/TLS. We find that many organizations become overwhelmed responding to the seemingly constant stream of changes required to maintain a secure web server, or simply throw their hands in the air and stick with a “good enough” configuration that seems to work. However, choosing and using strong TLS configurations doesn’t have to be hard. We wanted to create an easy to digest reference for all your SSL/TLS needs.

We built tlsconfig.neohapsis.com as a living information hub for SSL/TLS secure configurations. We test it regularly against known vulnerabilities and update it accordingly. The configuration examples available on the site will help strengthen your site and will also minimize low and medium risk findings on security assessments. More importantly, by using these configurations that emphasize best practices you can minimize reactionary patches and emergency configuration changes, and reduce time, effort, and risk.

Why Is “Good Enough” Not Good Enough?

Defense in depth is a concept that used a lot in the security world and it is just as important in SSL/TLS. The recent FREAK attack is a prime example of how a known-weak configuration that might currently be classed as a medium or low risk can suddenly become critical, resulting in downtime to fix and a fire drill for your system administrators. Over 12% of the most popular domains had to act quickly to patch the vulnerability which has been a known bad practice for 15 years (in fact, over 8% are still vulnerable and scrambling to update).

This is just one of many examples of the very good reasons that cryptographers are a conservative bunch and regularly deprecate old configurations. In short: proactive, gentle movement to the most current best practice configurations prevents unnecessary emergency maintenance and reduces overall risk.

Old Habits Die Hard

Aspiring for the shiniest new ciphers and configurations may not always be the wisest business decision. Often security best practices can conflict with market realities. Historically, adoption of new web technologies, including SSL/TLS technologies, has been slow; they are usually dependent on either operating system upgrades or hardware purchases, which are costly and rely on the user base willingness to upgrade. The most common reason we hear for use of deprecated cipher suites and weak key strengths is legacy support for Windows XP.

However, since the release of Windows 7, Windows XP has been seeing a steady decline of use across the Internet. By the time Microsoft stopped enterprise support for Windows XP, usage was down to 12.68%. Today usage is down to 7.36% and will only continue to fall. On top of the falling usage of XP, IE 6 usage has flat lined at 0.2% of total browser usage across the Internet. Only 7 years ago, one out of every two browser request was made by IE 6 and it was the driving force on a lot of development decisions. Sites were required to support IE 6 because of it’s wide spread use:today that is no longer the case. So, if your organization has historically made security choices for all users based on the the low bar of XP/IE6 users, now may finally be the right time to revisit that decision. In fact, comparatively strong cryptography choices can still support support browsers back to 2002 while allowing modern systems to take advantage of better ciphers.

This was cross-posted from the Neohapsis blog. 

General Privacy Vulnerabilities Webappsec->General
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.