How (un)safe are top 300 websites (SSL/TLS versions & forward secrecy support)

Latest year, Paul Querna wrote a great blog post titled Adoption of TLS extensions. In that post Paul primarily focused on the supported protocols and SSL/TLS extensions as advertised by the clients in the ClientHello message. He put special emphasis on the Web Services API clients.

In this post I’m going to ignore clients for the moment and focus on the protocols, extensions and cipher suites supported by the most popular websites on the internet. I’m going to give a special attention to cipher suites which offer forward secrecy.

Motivation

The most common way to protect communication and provide security when we talk about the web and web browser <-> web server communication is using SSL/TLS protocol.

Nowadays, SSL/TLS protocol has been highly adopted (both by clients and servers) and most of the popular websites are now accessible (only) over a secure SSL/TLS connection.

A full SSL handshake which is performed each time client requests a resource if no session resumption mechanism is supported

The main problem with a large chunk of the websites which are accessible over SSL/TLS today is that they don’t offer forward secrecy and protect data for the long term.

Because of the recent events, more people have become aware of the issues of privacy, security and equally or even more importantly, protecting data for the long term.

Some website like Google have served as a good example and supported forward secrecy for multiple years now, but I wanted to know what is the actual state on the web today and how many other top websites support it as well.

What is Forward Secrecy

Before diving into the results, lets quickly look at what forward secrecy is.

In public key cryptography, perfect forward secrecy (PFS) is a property of
the key-agreement protocol that ensures that a session key derived from a set
of long-term public and private keys will not be compromised if one of the
(long-term) private keys is compromised in the future.

In a typical website scenario this means that even if someone records all of the encrypted communication between a browser and server and at some point in the future obtains access to the private key, he won’t be able to decrypt the recorded traffic and obtain access to plain text version of the communication.

How the access to the private key is obtained is not important - it could either be obtained physically (e.g. by giving away private key file when receiving a warrant) or by breaking it when the computers get faster.

As demonstrated in the previous example, forward secrecy is an important property. Because of the aforementioned events more people have become aware of it and the webmasters / sysadmins became interested in configuring their web servers to support it.

Keep in mind that configuring your web server to prefer cipher suites which offer forward secrecy is not a good enough measure by itself. There are many ways to mess up the actual configuration. The most common ones are supporting session resumption (either via session ids or session tickets) and storing session information with a session key in memory or on disk for a prolonged time periods.

Adam Langley recently wrote a blog post titled “How to botch TLS forward secrecy” where he goes into details how you can mess it up. If you are interested in the details or you are deploying forward secrecy yourself I highly recommend you to check it out.

Methodology

For my sample, I decided to use top 300 websites as ranked by Alexa. You can find a full list of websites I decided to analyze here.

Keep in mind that this sample contains some outliers (e.g. localized versions of Google website which have been known to support forward secrecy for multiple years now) which slightly skew the results upwards.

After I have determined the websites I’m going to analyze, I needed to decide how I’m going to do it. There are many ways and tools which allow you to determine which SSL/TLS versions and cipher suites a web server supports:

Usually when I’m presented with a similar task I go with the openssl utility or the ssltest website. For this task I have decided to go with sslyze.

I have decided to use this tool because it supports all the protocols I’m interested in (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2) and saving the results into a file. This way I’ve saved myself some time writing a wrapper for openssl utility and I could spend more time analyzing the results.

The exact command I used is:

python sslyze.py --regular --targets_in=alexa_top_300.txt --xml_out=results.xml

To analyze the results I wrote a simple Python scripts which converts them into a CSV formatted file which I imported into LibreOffice Calc.

Original XML result file is available here and converted CSV file is available here.

Observations

I got a response back for 172 out of 300 websites I analyzed. The observations bellow are based on those 172 websites.

Supported SSL/TLS versions

Supported SSL / TLS versions

As you can see, most of the web servers support either SSL 3.0, TLS 1.0 or both, but less servers support TLS 1.1 and TLS 1.2.

This is expected because one of the most widely used and deployed openssl versions today is 0.9.8 and versions prior to 1.0.1 only support TLS 1.0 and lower.

Supported Session Resumption Mechanisms (Session IDs and Session Tickets)

Supported session resumption methods

Almost 80% of the analyzed websites support at least one session resumption mechanism. This is expected because all of the top 300 websites operate on a large scale where saving CPU cycles (and money) by reducing a number of full SSL handshakes makes a lot of sense and pays off even more.

Forward Secrecy Support

Forward Secrecy support

I indicated server as supporting forward secrecy if it supports at least one cipher suite with Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Diffie-Hellman (ECDHE) key exchange algorithm.

This method is not as sophisticated as the ssltest one, but it’s a start. Ssltest method takes into account cipher suites supported by modern web browsers and based on this data displays which browsers would negotiate a cipher suite which offers forward secrecy.

As far as this graph goes, this means even though it indicates forward secrecy support, your browser might negotiate a cipher suite which doesn’t offer it (it depends on your browser and the cipher suites it supports).

As just can see, just around 65% out of 172 websites I obtained data for support cipher suites with one of the above mentioned key exchange algorithms. This is more than I expected, but keep in mind, that this number is skewed slightly upwards because the sample contains 40 localized Google websites which all support cipher suites which offer forward secrecy.

Conclusion

I hope this quick analysis provided some interesting insights. My goal is to expand on it to include more useful information and write a similar post every six months to a year.

This way we can reflect back and hopefully next time more of the top websites will support newer and more secure (according to the currently available research and knowledge) SSL/TLS protocols and cipher suites.