We've been looking at this issue off and on for over a week now, and it's gotten complex enough it deserves a ticket.
ecdhe-ecdsa-aes128-sha is one of our mid ciphers - it's forward-secret (good), but not AEAD (not the best). This and other ciphers in its category have generally been on a slow downward trend over the past several months in favor of higher-security ciphers as older clients get upgraded. However, this one cipher has turned around a bit lately in our stats, and it's puzzling and potentially highlights an issue we don't understand here.
It first began trending upwards notably starting around June 1, but the rate of increase was negligible at the time. Around July 19th a more significant rise began, leveling off to a new high by around July 23. At this point it's ~3-4% higher (in terms of overall request-rate) than we expect from historical trends and is significant. We don't have historical data that correlates our cipher statistics against other factors (such as geographic location, user-agent, etc), so investigating this is a bit tricky without insightful historical comparisons.
In live logging today, we see the bulk of the influx on this cipher seems to be user agent strings indicating a very specific version of Chrome/41. The UA strings look like: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36, but the Windows version near the front does vary, at least as far back as Win8 and maybe Win7. These UAs (even when filtering on the UA rather than the cipher that lead us here) predominantly negotiate (according to our nginx header output) as TLSv1.1 with the ecdsa-ecdhe-aes128-sha cipher . We know Chrome/41 should be capable of TLSv1.2 and stronger (AEAD) ciphers, and probably was negotiating them before whatever event precipitated this.
There have been lots of avenues we've looked at, but so far the most-promising has been that Microsoft released some updates to their SChannel and CryptoAPI libraries for all supported Windows versions around the right timeframe for this, and Chrome/41 probably makes indirect use of those libraries for some parts of TLS negotiation and/or certificate verification.
The Windows 7 version of this update can be seen here (similar ones exist for other versions): https://support.microsoft.com/en-us/help/22801/windows-7-and-windows-server-2008-r2-update-history
It's possible (but not very!) that this is interrelated with recent reports of a DHE compatibility issue between OpenSSL and Windows, which is discussed here: https://github.com/openssl/openssl/pull/1320 . We're in the process of deploying the bugfix for this starting today - https://gerrit.wikimedia.org/r/#/c/301903/ .