Wikipedia's TLS Cipher stats | Hacker News Reader

Wikipedia's TLS Cipher stats

grafana.wikimedia.org

60 pointsmmastrac24 comments

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.

This is neat but kinda useless without some written analysis. I am not a crypto expert so the graphs mean little to me.

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.

And in which time zone is the time scale at all?

Thanks in advance.

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.

It is the only widely compatible AEAD for TLS. Soon, it'll be accompanied by ChaCha/Poly1305, but not yet.

GCM is the last AEAD I'd reach for in a custom design!

Besides not having to deal with the joinery, GCM is sometimes chosen for perf reasons (smaller output, cpu support, etc).

"Besides not having to deal with the joinery, GCM is sometimes chosen for perf reasons "

Although going by this,

https://www.imperialviolet.org/2013/10/07/chacha20.html

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.

disclaimer: no crypto expert.

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.

There is a RFC for EtM in TLS: https://tools.ietf.org/html/rfc7366

   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.

I remember https://twitter.com/nestsupport/status/606246459822997505 and other similar tweets days after I reported the 768-bit DHE problem to Google security. (affected server was https://transport01-rts10-iad01.transport.home.nest.com)

More of these stats here: https://grafana.wikimedia.org/#/dashboard/db/home

Man, you can tell when people are at home vs. at work...

Absolutely. DES-CBC3-SHA = people on IE8 on XP = people at work.

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).

Oh no. That's people at work. Notice how there are two days a week where it doesn't rise during the day.

We just don't appreciate how slowly many organizations update their "frozen rigid" workstations images.

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).

Interesting stats, but oh boy Grafana[1] looks amazing.

1. http://grafana.org/

And apparently des-cbc3-sha is still a thing...

Mostly XP by now I think.

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

Notice how it spikes during work hours and takes the weekend off? ;-)

Reply on news.ycombinator.com