A perspective on the state of the SSLiverse as of early 2016

tl;dr; Most studies about SSL tend to use SSL information retrieved by DNS domain names. This article provides an overview of the SSLiverse when SSL information is retrieved from each SSL enabled host in the IPv4 range on port 443.

With today’s state of the art scanning tools and proper infrastructure, it is now possible to crunch interesting data from Internet hosts on the IPv4 address space. The focus of this article is on SSL enabled hosts information. While most studies found on the web tend to consider SSL information retrieved via domain names, the numbers presented in this article propose a different perspective.

However, before I expose these interesting numbers, make sure to take note of the following:

• The scan from which this data comes from was performed in February 2016 (scans are conducted on a regular basis).
• Information was collected on a per IPv4 host basis. This means that only one (the default) certificate was retrieved for every host that was scanned.
• Only port 443 was considered. Scanning other ports for SSL information (such as 465, 993 or others) would probably expose slightly different data and be more accurate about the state of the SSLiverse.

Now that this is clear, let’s dig into the data, shall we?

Our scans are able to successfully establish an SSL connection on port 443 with a little over 33 million hosts. An interesting fact is that approximately 35% (~11.8 million) of the certificates that are retrieved are self-signed! This number is impressively high. I suspect that it might be due to the fact that the scans retrieve the default fallback certificate, i.e. the one that is presented when trying to establish an SSL connection via the host IP rather than one of its associated domain names. First off, people are usually tempted by self-signed certificate for one reason: they are free! But that’s about their only advantage. On the other hand, websites presenting a self-signed certificate will be blocked by modern browsers and put the client at risks (you know, that scary warning message that browsers display when visiting an SSL enabled website using a self-signed is there for a reason). With a self-signed certificate, clients have no guarantee that the server public key indeed belongs to the server they are visiting. Using methods such as DNS spoofing, a bad guy could impersonate the website the client believes he is visiting. Oh, by the way, if you are reading this and making use of self-signed certificates, consider Let’s Encrypt as they offer free, genuine SSL certificates. It’ll be for the greater good!

Anyway, what can be told about these self-signed certificates?

• 119K hosts (~0.01%) that provided a self-signed certificate are still vulnerable to Heartbleed(!).
• The certificate key algorithm used is RSA for 99.9% of these certificates. The key length is 1024-bit for the large majority (68.7%), followed by 2048-bit (28.6%) and … 512-bit (1.5%)!
• ~77% use RSA for their certificate signature with SHA1 (!) as the hash algorithm, ~12% with MD5 (!!) and ~10% with SHA256.
• The protocol version used once the connection was established ended up being TLSv1.0 for ~70% of the successful negotiations, followed by TLSv1.2 (~26%) and SSLv3 (~3.4%).
• Approximately one-third (~32%) of the hosts provided a certificate that was already expired at the time of the scan.
• The most common certificate validity period is one year (~35%), followed by… 10 years (!) (~31%), then 20 years (4.8%) and other spans. A non-negligible portion of the administrators of these hosts estimate that it will run for quite a long time as the certificate is valid for close to 70 years (~3.4%).

As a reminder, SSLv3 was deprecated in June 2015 and is no longer considered secure. Another aspect you should take note of is that TLSv1.0 includes a mechanism which permits downgrading the connection to SSLv3 if the latter is available. Presumably, a significant number of these hosts are hence vulnerable to POODLE though I do not have numbers to confirm this point. Note that the latest version of TLS is 1.2, this is the version preferred to establish a secure connection nowadays.

RSA is still considered secured today, provided that the key is large enough (2048 bits or more is preferred even though breaking 1024-bit RSA is yet to happen but factorization of a 768-bit RSA modulus was accomplished in 2010). Remember: 1.5% (~178K) of these hosts use RSA with a 512-bit long key!

The situation is also worrisome when it comes to the hash algorithm used for the certificate signature. It has been known for quite some time now that MD5 is not secure and can be exploited. With recent news about SHA-1 (the SHAppening), things do not look bright as only ~10% of the hosts are using the SHA256 hash algorithm (which is still considered safe today even though the SHA-3 successor already exists)!

We also noticed that self-signed certificates tend to have a very long validity period. It seems that people generating self-signed certificates just want to do it once and be done… In practice, this is not recommended. For instance, who knows if 1024-bit RSA won’t be broken within the next 10 years? Even if self-signed certificates are free and hence a long validity period can be set, one-third of the hosts still manage to present an expired certificate. While this does not really matter for self-signed certificates, it still gives an idea about how administrators of these hosts care about the security of their users.

All of this is interesting but what about the ~21.4 million hosts that did not present a self-signed certificate? Let’s find out!

• 80.3K (~0.004%) are still vulnerable to Heartbleed. The overall proportion of Heartbleed vulnerable hosts is much reduced compared to hosts providing a self-signed certificate. This is a very good point actually.
• The certificate key algorithm used here is RSA for 99.7% of the certificates. Without surprise, this proportion is similar to the self-signed certificates here. The key length distribution, however, is much better: 85.6% use a 2048-bit long key, while 12.6% use a 1024-bit long key. Even better: 1.69% use 4096-bit long key while 512-bit long RSA keys are pretty much gone!
• ~34% use RSA for the certificate signature with SHA1 as the hash algorithm. Again, the proportion is quite reduced here! So what other hash algorithm are used then? SHA256 accounts for ~65% (again that’s a very good point!) where MD5 accounts for ~1% (that’s bad but, the proportion is considerably reduced here).
• About the protocol version after a successful negotiation, numbers are better here as well. ~67% of the connections ended up using TLSv1.2, ~28% TLSv1.0 and TLSv1.1 for ~5%. Note that SSLv3 is close to 0 here, which is good news!
• OCSP stapling is enabled on ~1.5 million hosts.
• Over a million hosts (~4.9%) presented an expired certificate. It seems, that administrators who do not sign SSL certificates themselves are more responsible with regard to this matter. However, this is not great because an expired certificate means its revocation status cannot be checked and there are still over a million hosts in this case!
• The most common validity duration is a year (43%), followed by 3 years (16.3%), 2 years (13.4%) and 10 years (8.2%). A very long validity duration is almost never found, which sets it apart from the numbers related to self-signed certificates.

Our scans revealed that the proportion of self-signed certificates is quite high, I thought it made sense to break down the stats into self-signed vs properly signed certificates. It appears that servers providing a self-signed certificate are generally in a much worse state that their counterpart. However, even though 2/3 of the hosts with properly signed certificates have TLSv1.2 enabled, only a small portion of them have OCSP stapling configured. As a reminder, OCSP stapling is mostly a convenient feature as it eliminates the need for clients to contact the certificate authority to check for the revocation status. If the Certificate Authority (CA) servers are really busy, checking for the revocation status might slow down browsing if OCSP is not enabled.

Last October, Netcraft announced that “one million SSL certificates (are) still using the insecure SHA-1 algorithm”. Well, I think the numbers presented in this article put me in a position to affirm that things are worse than that: half of the scanned hosts (~16.4 million) presented a certificate using SHA1 as the hash function. Hence, SHA1 still seems dominant over SHA256 (~45%). Admittedly, when self-signed certificates aren’t taken into consideration, things are better (~65% for SHA256 and ~34% SHA1) but the numbers show that approximately 7.2 million hosts still use SHA1.

This week, you probably heard about the DROWN vulnerability which affects services that rely on SSL and TLS. The data presented here was collected prior to the vulnerability being publicly disclosed which explains why there is no information about DROWN in the stats. Nonetheless, I remind you that if you haven’t done it already, you should disable SSLv2 on your server. Also, even if SSLv3 is not concerned by DROWN, you should disable it as well since it is broken (remember POODLE which I mentioned here?). There is no point in supporting broken protocols if you care about the security of your users!