Menu

CA

While last month’s results were not very interesting, this month is anything but.

But before we go into results, there were few small changes to how the statistics are reported. First difference is that the “x:FF 29 RC4 Preferred” now includes sites that prefer RC4 ciphers independent of other ciphers. Second is the addition of new item “Insecure”, which is the sum total of sites that use any cipher with a “z:” state, it does not include sites that also include IDEA or SEED ciphers. Ciphersuites that use those two ciphers are now prefixed with “y:”, as they are iffy in the sense that they haven’t been widely analysed, but otherwise don’t have known weaknesses.

Since the last scan two big things happened. POODLE attack that has shown SSLv3 to be completely insecure in CBC mode and Cloudflare deploying their Universal SSL.The former should cause far less sites to have SSLv3 enabled while the former should show more sites using ECDSA certificates and more TLS enabled sites in general.

Cipher suite results

This time ’round, the number of TLS enabled servers has increased by over 33 thousand (7.6%) a much bigger amount than previous months.

Usage of AES-GCM has increased by 5.5% to 48.3%. Surprisingly the percentage of CAMELLIA enabled servers has fallen, but it’s caused by the overall increase of number of TLS enabled servers, not by fewer servers supporting this cipher.

As far as bad choices go, sites that use completely broken ciphers (AECDH, single DES, export grade, etc.) has fallen by 2.6% to 20.3%.

RC4 is still a problem, percent of servers that support it has fallen by just 2%. Percentage of servers that don’t support anything else has decreased by just 0.13% to 0.82%. It’s a biggest drop in months, but it still makes it impossible for browser vendors to drop it completely. Similar fate share servers that prefer RC4 where their numbers fallen by just 2.28% to 15.5% of total. The good news is that it’s a reversal of a few months negative trend.

Misconfiguration that causes AECDH ciphers to be enabled is still common, just 0.6% fewer servers support it compared to last month, bringing their numbers to around 3.2%.

Cipher ordering has shown a big shift this time, just over 60% server now use their order instead of client side order, a change of over 5%!

There is also a rather big up-tick in fraction of servers that don’t enable the RSA key exchange, from less than a 1% to nearly 4% now.

More servers also started preferring Forward Secrecy: an increase of 3.8% to 68.6%. Also more servers support PFS now: 2.2% more for a total of 82%.

Server certificates

Another significant change are the certificates used by servers, while previously just 4 servers did use certificates signed by a ECDSA CA, now there are nearly 21 thousands of them, giving a total of 4.8% of servers using them. The servers that use RSA CAs have also seen a big change, nearly 4% more servers now have their certificates signed with SHA256, to a total of 20.5%.

The vast majority of those new ECDSA certificates use P-256 curve, a total of 6.6%, creating an increase of 4.5%.

Protocols

Obviously SSLv3 support has taken a blow, its use has fallen by over 26%, bringing its support to 69.5% (far too small change given the severity of POODLE). It looks like many administrators also have taken the time to actually update the cryptographic libraries they use, as TLS1.2 support has increased by 4.5% to a total of 64%.

Trust chains

With the introduction of ECDSA CAs, we can finally see a significant percentage of servers reach 128 bit level of security. We can also see that all of intermediate ECDSA CAs have been signed with SHA384. No big changes besides that.

Mozilla is working towards removal of all 1024 bit CA certificates in their trust store. That means that if you depend on root CA or intermediate CA that has those weak RSA keys, your website or server may stop working in near future.

The first batch of changes will affect Firefox 32 users and Fedora 20 (after updating to ca-certificates-2014.2.1-1.0.fc20).

Go to kuix.de for more information, how to tell if you’ll be affected (without using Qualys SSL Labs scanner) and what to do if you are.

This month’s scan results are a bit later than previous ones, this was caused by me working on code to compile statistics of the certificates used by Certificate Authorities (see further below for results of this part of the scan). The state of TLS and crypto in general in python didn’t help much, but that’s a topic for another post, for now I can direct you to the very good presentation by Hynek Schlawack: The Sorry State Of SSL (the python specific part is towards the end).

Ciphersuites

All in all, the results haven’t changed much. We can see the continuation of the downward trend for RC4 Only servers, the unfortunate upwards trend of servers that prefer RC4 but support other ciphers and the very good trend of SHA256 certificate signatures.

The new addition are the “x:FF 29” lines that account for situations for which Firefox cipher selection (advertised support) causes it to negotiate different cipher suites than OpenSSL would negotiate. In other words, for Firefox, the percent of servers that are RC4 only is around 2.6% and servers which prefer RC4 but support other ciphers is at around 21.8%.

It also looks like many people that update their servers/OpenSSL, don’t update their cipher strings, which makes servers that used “!ADH” in cipher string negotiate AECDH cipher suites (to prevent it from them doing that, you should use “!aNULL” which will disable all anonymous cipher suites, present and future, head over to Mozilla guide for more details). The amount of them has grown from 2.9% to 3.3%.

Amount of servers that support PFS haven’t changed, as well as the PFS mechanisms they support.

We also see continuation of the trend of SHA256 signatures in certificates, it has grown from 11.9% to 12.7%.

Used key sizes haven’t changed much.

Surprisingly the amount of servers that support OCSP stapling has dramatically decreased, from 14.9% to 10.1%. I have no explanation for that.

The percentage of servers that support only SSL3 or TLS1 has dropped from 41.5% to 30%, but this is likely caused by the reintroduction of proper SSLv2 fingerprinting rather than changed configurations as the amount of servers that support TLS1.1 or TLS1.2 haven’t changed to match. Previous months’ low percentage of SSLv2 servers was caused by a bug in scanning script that made it impossible to correctly detect most SSLv2 sites.

Certificate Authorities

The new addition to the data collected, were the certificates provided by the servers.

It looks like around 5% of Internet facing www servers have misconfigured certificate chains: they don’t provide the intermediate CA certificates that signed their certificate. Fortunately, because we now have collected them from other servers, we can try to validate them again using those additional certificates.

The bad news is that many CA certificates still use 1024 bit RSA keys (I’ve seen them in 1776 chains presented by servers, or 0.4% of all valid chains), including few root CAs in active use. The worse news is that the vast majority of chains still depend on SHA1 signatures, including the chains that use 4096 bit CA keys.

In effect, about 90% of trust chains still provide at most 80 bit level of security (SHA-1 or 1024 bit RSA key being the weakest link) and just 10% of servers present chains with 112 bit level of security (2048 bit RSA key being the weakest link). There were only 2 chains (out of 450 000) that reached the current best practice level of 128 bit level of security (SHA 256, ECDSA 256 bit or RSA 3072+ bits).

Also, the market share of CAs is quite diverse, the most dominant root CA was used in 26% of all chains collected.