Web security is hard.  Making things even more difficult is the rate of change for what is considered “secure.”  That being said, the topics covered in this article can be considered current as of the date of publication.  Things may have changed, YMMV.

Now that you’ve been warned, let’s get back to the topic at hand…

Today we are talking about two components of a secure web connection: the protocol and the cipher suite.  If you imagine the protocol defines how the lock and key function the cipher defines different ways to make the ridges on the keys.

Protocols

SSL

When HTTPS was born the first iteration of the protocol was known as SSL (Secure Socket Layer).  SSLv1.0 never actually “made it out of the lab” making the first public release of the protocol SSLv2.0 in 1995.  SSLv3.0 was released in 1996 representing a complete redesign of the protocol which would become the basis for future work.

Due to vulnerabilities and increasing compute speed SSLv2 was considered obsolete in 2011 and SSLv3 in June 2015.

This is why you need to be scanning for and deploying modern crypto.  You can read about some tools and challenges here: Beware the False Negative -SSLv2 Detection Issues

TLS

TLS 1.0 was introduced in 1999 but had interoperability issues with SSLv3.0 and ultimately a downgrade vulnerability was discovered allowing clients to bypass TLS 1.0 and fall back to SSLv3.0 when it was also available.  (Disable SSLv3!!!)

TLS1.1 was defined in 2006 and is currently considered secure but not preferred.

TLS 1.2 was defined in 2008 and is considered the current “secure” standard (when configured with the correct options and cipher suite).  This is the option you want to make sure to support.  Everything else is for backward compatibility, at least until TLS 1.3 is released.

TLS 1.3 is very close to being ratified (2017).  Once approved it will take some time for the servers and the browsers to release stable implementations of the protocol.

You can read some considerations about backward compatibility in my post: HTTPS, check. Secure? Maybe…

Cipher Suites

Cipher suites are a combination of complex mathematical functions for which both the client and server must agree for the connection so proceed successfully.

In the TLS supported cipher suites have 4 parts:

• Key Exchange Algorithm
• Bulk Encryption Algorithm
• Message authentication code (MAC)
• Pseudorandom function

Each of these areas is complex enough to merit a post of their own (and maybe I will!) but it is beyond the scope of this post to get into the details.

What I will leave you with is what is currently considered the secure cipher suites:

Modern (Most secure):

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256

Intermediate (Compatible):

This has removed the known problematic cipher suites but keeps many older but ‘safe’ (for now) suites:

• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES128-SHA
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES128-SHA
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-ECDSA-AES256-SHA
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES128-SHA256
• DHE-RSA-AES128-SHA
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES256-SHA
• ECDHE-ECDSA-DES-CBC3-SHA
• ECDHE-RSA-DES-CBC3-SHA
• EDH-RSA-DES-CBC3-SHA
• AES128-GCM-SHA256
• AES256-GCM-SHA384
• AES128-SHA256
• AES256-SHA256
• AES128-SHA
• AES256-SHA
• DES-CBC3-SHA:!DSS

More information on cipher selection can be found at mozilla.org.

Cipher Suite Order

Are we done yet?  Almost!

Make sure your web server is configured to enforce cipher order.  The way they are listed above is in order of “most to least” secure.  Browsers (behaving properly) should select the most secure supported common cipher suite and complete the connection.

HSTS

You said almost done!  I did.  I lied, but, it was for the greater good.  Consider this a bonus tip.  Make sure HSTS is configured on your platform.  This forces the browser to use a secure connection in the event a clear text connection is also available.

That’s it for real this time!  Hope you enjoyed the article.

Feedback is welcome in the comments.  You can follow me on Twitter @JaredGroves