How widely deployed is TLS with cipher ECDHE?

Question

Microsoft deployed a patch for Windows 2012 R2 and Windows 8.1 that adds the following ciphers.

Cipher suite                      Exchange  Encryption  Hash
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384     DH  AES         SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256     DH  AES         SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384         RSA AES         SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256         RSA AES         SHA256

ECDHE is missing (note the first set of letters in the cipher name after TLS_)*. Grumblings about this lack of ECDHE support is also mentioned on the CERT forum thread

Question

• Is there any TLS Survey that scans TLS cipher support in Websites for ECDHE?
• How widely supported is ECDHE in the client?

Based on Microsoft's history, they might not prioritise ECDHE support until it's widely in use by servers, or web browsers. I hope to use this information to estimate if/when MSFT may include such support in SChannel.

*Aside: why do I want ECDHE? Because it's faster.

Answer 1

Last year (May 2013), I ran an experiment by contacting SSL servers randomly: I was connecting to port 443 of random IPv4 addresses and, if I received a response, my client engaged in a series of aborted handshakes in order to work out what cipher suites were actually supported by the server. I tried a few millions of addresses, and found about 13000 servers speaking SSL/TLS over port 443.

Of these, about 7.5% supported an ECDHE cipher suite.

Mind the details:

• This was one year ago. Things may have changed since.
• My client did not send any extension claiming support for any specific elliptic curve. It was only claiming "generic" ECDHE support. This may have prevented some servers from trying ECDHE cipher suites. In that sense, my figure may be an underestimate.
• A corollary is that "ECDHE support" cannot be stated really generically. Many ECC implementations are limited to some curve types, most of them being able to process only a couple specific curves (the P-256 and P-384 standard NIST curves, so-called "suite B").
• There are several ways to make sampling measures. My code was using random IPv4 addresses, thus finding not only Web sites but also many systems like home modems/routers. Existing, published SSL surveys like that one use the "top 1 million Web servers" from Alexa; this favours a notion of "economical significance" which may or may not map to what you want. Concentrating on "top sites" weeds out unmaintained SSL servers and, indeed, home modems and routers, which should increase ECDHE support. Indeed, that survey (from early 2014) finds that a whopping 21.6% of these "top sites" support ECDHE cipher suites.

As a side note, I must say that in most cases, performance increase implied by ECDHE (over DHE) is unlikely to be relevant. It takes an awful lot of connections per second to a basic Web server to actually see the difference (we are talking hundreds per second here). Another salient point is that you get the performance increase by supporting ECDHE cipher suites, and configuring your client or server to prefer such cipher suites when possible; you don't need to stop supporting non-ECC cipher suites to get that purported speed bonus. In that sense, decision to enable ECDHE cipher suites does not need to be backed by figures on who supports them and who does not; you can just activate them and use them opportunistically.

Answer 2

The strange thing is, Microsoft offers GCM and ECDHE, but not both together with RSA certification. The only AES-GCM ciphers with ECDHE are tied to ECDSA. Otherwise GCM is only available with DHE_RSA.

The list can be found in KB2929781 or the IISCrypto tool shows it. IE11 seems to have the same restrictions.

I really wish they would implement TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 from RFC5289 (like GWS does).

Answer 3

EDIT: there is a new survey by qualys for clients:

User Agent Capabilities

TLS 1.2 is needed for ECDHE (afaik), but having TLS 1.2 enabled doesnt necessarily mean that ECDHE is available.

for a overview on the ssl-setup of alexa top 1 million you might want to check ssl pulse @ qualys

SSL Pulse is a continuous and global dashboard for monitoring the quality of SSL support across the top one million web sites. SSL Pulse is powered by the assessment technology of SSL Labs, which is focused on auditing the SSL ecosystem, raising awareness, and providing tools and documentation to web site owners so they can improve their SSL implementations

for clients: all i found (and know of): most modern browsers implement ECDHE, meaning probably chrome and firefox and the most recent versions of safari and ie (but i'm not sure).

you need to offer DHE as well to enable PFS on older browsers. TLS-version used might depend on the os-version used.

Answer 4

Some statistics from firefox telemetry. The link points to the usage statistics for the SSL_CIPHER_SUITE_FULL variable for firefox 32, showing which suite is actually used for connection between the release of firefox 32 (early september 2014) and today (early november 2014). Its values are defined in the firefox source code. Boiled down we have:

• 48% connections using TLS_RSA_*

• 45% connections using TLS_ECDHE_*

• 7% connections using TLS_DHE_*