Announcing SSL Pulse

Ivan Ristic

Last updated on: October 21, 2021

Today we introduce SSL Pulse, a continuously updated dashboard that is designed to show the state of the SSL ecosystem at a glance. While it is possible today to deploy SSL and to deploy it well, the process is difficult: the default settings are wrong, the documentation is lacking, and the diagnostic tools are inadequate. For these reasons, we cannot say that the Web is yet secure, but we hope that someday it will be. The purpose of SSL Pulse is to bring visibility to SSL implementation issues on the Web, and while businesses are starting to fix these issues we can keep track of progress made towards making SSL more robust and widely adopted on the Internet.

SSL Pulse is based on the assessment technology and testing conducted by SSL Labs. The underlying data set draws from the information on about 200,000 SSL web sites that represent the most popular web sites in the world. We cherry-picked only the most important data points, focusing especially on those aspects where improvements are needed. We have so far conducted only one round of testing, but, when the next month’s results become available, we will start to show historic values and hopefully see improvements for each data point.

So what do the results tell us? Looking at the SSL Labs grades, which are designed to sum up the quality of SSL configuration, we can see that about 50% (99,903 sites) got an A, which is a good result. Previous global SSL Labs surveys reported about 33% well-configured sites, which means that more popular sites are better configured. Unfortunately, many of these A-grade sites (still) support insecure renegotiation (8,522 sites, or 8.5% of the well-configured ones) or are vulnerable to the BEAST attack (72,357 sites, or 72.4% of the well-configured ones). This leaves us with only 19,024 sites (or 9.59% of all sites) that are genuinely secure at this level of analysis.

The number of sites vulnerable to insecure renegotiation is decreasing at a steady pace, as patches are applied or servers get replaced. The very high number of sites vulnerable to the BEAST attack is worrying, because this problem needs to be addressed in configuration, and that requires awareness, time, and knowledge. Plus, freshly installed systems are equally likely to be vulnerable because of the insecure defaults.

Among other interesting data points, we found only 19 weak private keys in our data. There are also 9 keys that trigger our black list of weak Debian keys. The support for HTTP Strict Transport Security, which is the state of the art configuration for SSL, is at 0.85% (1,697 sites).

As part of this effort, we also published an SSL/TLS Deployment Best Practices guide with clear and concise instructions to help overworked administrators and programmers spend the minimum time possible to deploy a secure site or web application.

Update June 2017: SSL Pulse is now part of SSL Labs.

Show Comments (7)

Leave a Reply to Ivan Ristic Cancel reply

Your email address will not be published. Required fields are marked *

  1. in the server test suite you should also test if the server is affected by one of the known TLS 1.2 incompatibilities. Affected are for example F5 BigIP customers who didn’t update their Firmware recently. They are no longer reachable by clients using openssl 1.0.1. The problem is not TLS 1.2 of openssl but the bigger client hello packet. The Big-IP loadbalancers just drop TLS connections with a client hello that exceeds a certain size.

    And, HELLO QUALYS … https://community.qualys.com is affected by the same issue, interesting that YOU have not been aware of that already.

    Would be great to see a "big client hello test" being added to http://www.ssllabs.com/ssltest/ resp. SSL Pulse.

    References:

    http://rt.openssl.org/Ticket/Display.html?id=2771

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452

    http://support.f5.com/kb/en-us/solutions/public/13000/000/sol13037.html

    1. Carl_B, are you asking about a dashboard with public web sites on it, or one that covering only sites internal to your organisation? I am sorry we have no plans for the former, but have been receiving many questions about the latter recently.