One of the most challenging task of editing Server Side TLS is figuring out which ciphersuites are appropriate in which levels. Over the years, we've made judgment calls based on our experience and understanding of the TLS ecosystem, but finding hard data about clients in the wild is always difficult.
For the next revision of the guidelines, I wanted to collect real-world data to decide if we could prune unused ciphersuites from the Intermediate configuration. People often complain that the list of ciphersuites is too long. So far, we've taken a conservative approach, preferring a long list of ciphersuites that accepts all clients rather than being restrictive and potentially breaking the Internet for a minority on unusual devices.
Collecting TLS statistics is actually harder than one might think. Modern infrastructures terminate TLS ahead of application servers and don't always provide ciphersuite information in their logs. We run most of our services in AWS behind ELBs, so there's no way to collect statistics at scale.
Last year, we moved mozilla.org behind Cloudflare to support certificate switching and continue serving our users on very old systems. A few months ago, Cloudflare added TLS protocol and ciphersuite information to their access logs, so we finally had a solid data source to evaluate client support.
Mozilla.org is an excellent target to evaluate client diversity because it receives traffic from all sorts of devices from all over the world. It's not an opinionated site that only certain type of people would visit. It's not region or language specific (the site supports dozens of languages). And it's the main entry point to download Firefox.
I collected logs from Cloudflare intermittently over the course of a few weeks, to get an evenly distributed sample of clients connections. That data is represented in the table below.
| Percentage | Hits | Protocol | Ciphersuite |
|---|---|---|---|
| 80.300% | 1300142157 | TLSv1.2 | ECDHE-RSA-AES128-GCM-SHA256 |
| 9.900% | 160597128 | TLSv1 | ECDHE-RSA-AES128-SHA |
| 2.800% | 45350538 | TLSv1 | DES-CBC3-SHA |
| 2.500% | 42058051 | TLSv1.2 | ECDHE-RSA-CHACHA20-POLY1305 |
| 2.000% | 33972517 | TLSv1.2 | ECDHE-RSA-AES128-SHA256 |
| 0.800% | 13869096 | none | NONE |
| 0.400% | 6709309 | TLSv1.2 | ECDHE-RSA-CHACHA20-POLY1305-D |
| 0.200% | 4311348 | TLSv1 | AES128-SHA |
| 0.200% | 3629674 | SSLv3 | DES-CBC3-SHA |
| 0.100% | 3155150 | TLSv1.1 | ECDHE-RSA-AES128-SHA |
| 0.100% | 1968795 | TLSv1.2 | AES128-GCM-SHA256 |
| 0.000% | 1110501 | SSLv3 | AES128-SHA |
| 0.000% | 860476 | TLSv1.2 | ECDHE-RSA-AES128-SHA |
| 0.000% | 540913 | TLSv1.2 | AES128-SHA256 |
| 0.000% | 139800 | SSLv3 | ECDHE-RSA-AES128-SHA |
| 0.000% | 83537 | TLSv1.2 | AES128-SHA |
| 0.000% | 77433 | TLSv1.1 | AES128-SHA |
| 0.000% | 16728 | TLSv1.2 | DES-CBC3-SHA |
| 0.000% | 5550 | TLSv1.2 | ECDHE-RSA-DES-CBC3-SHA |
| 0.000% | 2836 | TLSv1.2 | AES256-SHA256 |
| 0.000% | 2050 | TLSv1.2 | ECDHE-RSA-AES256-SHA |
| 0.000% | 1421 | TLSv1 | ECDHE-RSA-DES-CBC3-SHA |
| 0.000% | 570 | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 |
| 0.000% | 386 | TLSv1 | ECDHE-RSA-AES256-SHA |
| 0.000% | 141 | TLSv1.2 | AES256-SHA |
| 0.000% | 128 | TLSv1 | AES256-SHA |
| 0.000% | 66 | TLSv1.3 | ECDHE-RSA-AES128-GCM-SHA256 |
| 0.000% | 32 | TLSv1.2 | ECDHE-RSA-AES256-SHA384 |
| 0.000% | 24 | TLSv1.1 | DES-CBC3-SHA |
| 0.000% | 8 | SSLv3 | AES256-SHA |
| 0.000% | 8 | SSLv3 | ECDHE-RSA-AES256-SHA |
| 0.000% | 8 | SSLv3 | ECDHE-RSA-DES-CBC3-SHA |
| 0.000% | 8 | TLSv1.1 | AES256-SHA |
| 0.000% | 8 | TLSv1.1 | ECDHE-RSA-AES256-SHA |
| 0.000% | 8 | TLSv1.1 | ECDHE-RSA-DES-CBC3-SHA |
| 0.000% | 8 | TLSv1.2 | AES256-GCM-SHA384 |
Unsurprisingly, ECDHE-RSA-AES128-GCM-SHA256 accounts for over 80% of the traffic, as this ciphersuite is preferred in both Firefox and Chrome. It's a good news that most of our users benefit from that level of security, but it doesn't help us understand backward compatibility challenges.
More interesting are the following two entries that both negotiate TLSv1 with ECDHE-RSA-AES128-SHA (9.9%) and DES-CBC3-SHA (2.8%). Almost 13% of the traffic to mozilla.org is stuck in TLSv1 land. The presence of DES-CBC3-SHA in third position is a strong sign that we're nowhere done supporting old clients that don't even know what AES is.
The stat I was most curious about is in 9th position: SSLv3 with DES-CBC3-SHA, which accounts for 0.2% of the traffic, is a signature from Windows XP pre-sp3 clients, when SChannel didn't support TLSv1 or AES. 0.2% may seem insignificant, unless you're one of these users and the only way you will browse the internet is by first downloading Firefox from mozilla.org. We certainly don't recommend for anyone to enable SSLv3 on their site, unless you're in this very special category that needs backward compatibility with very old clients. Mozilla.org is one of those sites.
The rest of the stats are mostly what one would expect: a long list of randomly ordered ciphersuites from devices with a variety of preferences. ECDHE-RSA-CHACHA20-POLY1305 is in that list, but only at 2.5%. Cloudflare doesn't support any of the legacy ciphers like CAMELLIA or SEED, so we can't see if any of those are in use (I would expect them not to be, but who knows...). We can also assume that the handful of SSLv3 connections at the bottom are scanners, since I doubt we have many clients stuck in SSLv3 but with ECDHE-RSA-AES256-SHA support.
What are we missing?
The information we're missing the most is DHE support. Cloudflare doesn't enable it anymore, and it would be interesting to know how many clients out there will only negotiate DHE. I'm suspecting most will fall back to some non-PFS AES based ciphersuite, but proof would be nice. Ultimately, removing DHE from the Intermediate recommendations is a goal, given how difficult it's been for operators to generate DHE parameters securely.
Statistics on ECDSA usage would also be nice. We currently use RSA certificates for mozilla.org, but we're more and more recommending ECDSA certs instead (P-256 is preferred in the Modern configuration level). An interesting experiment would be to perform cert switching between RSA SHA1, RSA SHA256 and ECDSA SHA256.
In conclusion
This data is good enough to start drafting the next edition of Server Side TLS. We'll look at removing DHE support from the Intermediate configuration, and maybe limit the non-PFS ciphersuites to one or two AES fallbacks. It would appear, however, that DES-CBC3-SHA is here to stay for a little while longer...
