The big graph at the top might be better represented as fractions of the whole. The most apparent thing in this graph is its seasonality / cyclic behavior in traffic, but that’s not the most important thing (given this was submitted as “TLS Cipher Stats,” not “traffic spikes”). Essentially, I’m saying the vertical axis should have percent labels instead of raw numbers.
I think your comment eats to the heart of what's been happening of late. You shouldn't need to be a crypto expert to know what Forward Secrecy or ECDHE are, at least.
Anyone who might ever configure a webserver should be learning about this stuff.
I'm glad that at least you find the graphs obvious, as I have a bunch of questions.
What are security pros and cons of using or not using GCM?
And which browser uses which settings of these displayed by default? How can we interpret the percentages?
What are the percentages anyway? It's hard to see them from all these graphs. Actually, I don't care about the peak-hour times when I just need to know the percentages.
GCM is "authenticated encryption". That means that it's a cipher construction that provides both confidentiality and integrity, in one hermetically sealed capsule. Most legacy crypto (and most of the crypto in TLS) provides integrity checking as a separate operation; it will, for instance, take confidentiality from AES-CBC, and authentication from (say) HMAC-SHA1. This works fine, but requires that implementations do joinery between the cipher and the MAC.
Every iteration of TLS prior to the version that began providing authenticated encryption (of which GCM is the only widely compatible option) has gotten this joinery wrong.
There are workarounds for the resultant bugs, but it's better, when possible, to enable the version of TLS that enables GCM, and prefer the GCM ciphersuites.
You almost imply that GCM is the only authenticated encryption. People should know that it is just one of them, but it is the one that circumvents patents and is really reasonably fast.
AES-GCM has performance issue when it comes to software implementations. The reason chrome added ChaCha20+Poly1305 as an option in chrome (when talking to google services). Now, it basically comes down to hardware support and it's not yet near universal in the current install base of mobile devices (all the myriad arm cpus floating around in the world).
It performs OK in software, but a fast pure-software implementation requires secret-dependent table lookups, which creates a hard-to-mask side channel.
There's a concept of authenticated encryption, so your connection isn't just confident, you're also making sure nobody tampered with the content. There are multiple ways to assure that.
This document describes a means of negotiating the use of the
encrypt-then-MAC security mechanism in place of the existing MAC-
then-encrypt mechanism in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has
been the subject of a number of security vulnerabilities over a
period of many years.
That also describes MtE. GCM in itself is already authenticated so it skirts the migration issue.
Funny, I was about to say that was people at home. I haven't used XP at work in years, but still ran it at home up until a couple of months ago (didn't use IE though).
Moving to a 14-day view, what accounts for the spike in ecdhe-ecdsa-aes128-gcm-sha256 and ecdhe-ecdsa-aes128-sha? Did these switch to preferred defaults in some major browsers?
It's a display problem. The spike appears at 2015-09-08 12:00ish, but is not visible at the same time on the shorter timescale views.
Edit: yes, it's aggregating things incorrectly at 14+ days. Some parts of the graph appear to be 'aggregate' (spike), others appear to be 'average' (low points).
Correct. For example Mozilla's recommended TLS server settings (which are fairly popular) will result in XP+IE8 (default browser) using TLS_RSA_WITH_3DES_EDE_CBC_SHA
