Skip to content

[2016-09-01 08:00:00 UTC] YubiCloud cipher changes and statistics


In the past, the TLS configuration for YubiCloud has differed slightly between each api* machine, due to different web server, SSL/TLS libraries and operating system versions.

When deciding which TLS cipher suites to support, and their preferred order, we typically follow Mozilla TLS guidelines. However, these are only a rough guide, and sometimes we have to make slight changes to support different client configurations.

YubiCloud has a certain requirement where a wide array of clients has to be supported, some of which are using very old software.

A little bit over a year ago, while upgrading from Ubuntu 12.04 to newer LTS releases, we ran into a problem with some of our Java-based clients. The issue was that we had DH key-exchange enabled with a minimum prime bit length of 1024, but the newer Apache HTTP Server bundled with Ubuntu, only support >= 2048-bit primes.

These clients abort the TLS negotiation and hence fail to establish a connection with YubiCloud.

In the rush to solve this issue, we disabled DH ciphers on and, so that these clients could communicate with some of the YubiCloud machines using RSA+AES. This allowed such clients to stop trying to negotiate DH (where they would fail due to large primes) and fallback to the next preferred cipher suite of RSA+AES (which, unlike DH, does not support Perfect Forward Secrecy).

This Summer, we have been working on standardizing the TLS configuration across the YubiCloud. To start with, we looked at what cipher suites were actually being used by clients.

We realized that roughly 95% of our clients negotiate TLS sessions using ECDH. The rest use a mixture of DH and RSA. The ones using RSA for key exchange typically fall into using AES or 3DES as the encryption algorithm.

To have the same TLS cipher suite (and preference order) across all api* machines, we needed to make a decision on whether to support DH key-exchange with a minimum of 2048-bit primes, or disable it completely, hence leaving new clients to use ECDH exclusively and old clients to use RSA+AES.

Considering that less than 1% of our clients use DH, we decided to drop it. Such clients that want PFS should consider upgrading their TLS stack to support ECDH.

Up until now, DH has been disabled on all api* machines except for On September 1st, 2016, we will disable DH completely across YubiCloud. The TLS configuration will hence be as follows:

~$ openssl ciphers "EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES" | tr ':' '\n'

Clients using DH should automatically have their TLS negotiation to fallback to RSA+AES (one of the AES128* or AES256* suites). We have observed this behavior while switching off DH on api 1, 2, 3 and 5.

We highly recommend to upgrade your software to support ECDH.

Some statistics showing cipher suite usage across the YubiCloud are displayed below. This data represents OTP verification requests using TLS between 2016-08-15 and 2016-08-28 (inclusive).

Cipher suite usage for each YubiCloud api* machine:

API 1:

87.01% ECDHE-RSA-AES128-GCM-SHA256
 3.30% ECDHE-RSA-AES128-SHA256
 1.72% AES128-SHA
 0.47% DES-CBC3-SHA
 0.38% AES128-SHA256
 0.04% AES128-GCM-SHA256

API 2:

65.79% ECDHE-RSA-AES128-GCM-SHA256
 4.72% AES128-SHA
 1.98% DES-CBC3-SHA
 0.57% ECDHE-RSA-AES128-SHA256
 0.45% AES128-SHA256
 0.04% AES128-GCM-SHA256

API 3:

78.73% ECDHE-RSA-AES128-GCM-SHA256
 3.20% AES128-SHA
 1.18% DES-CBC3-SHA
 0.39% AES128-SHA256
 0.24% ECDHE-RSA-AES128-SHA256
 0.04% AES128-GCM-SHA256

API 4:

62.29% ECDHE-RSA-AES128-GCM-SHA256
 3.02% DHE-RSA-AES128-SHA
 2.06% DES-CBC3-SHA
 0.79% DHE-RSA-AES128-SHA256
 0.49% DHE-RSA-AES128-GCM-SHA256
 0.02% ECDHE-RSA-AES128-SHA256
 0.00% AES128-SHA

API 5:

63.00% ECDHE-RSA-AES128-GCM-SHA256
 5.94% AES128-SHA
 2.22% ECDHE-RSA-AES128-SHA256
 1.09% DES-CBC3-SHA
 0.68% AES128-SHA256
 0.04% AES128-GCM-SHA256

Global cipher suite usage across the YubiCloud:

78.35% ECDHE-RSA-AES128-GCM-SHA256
 2.64% AES128-SHA
 2.03% ECDHE-RSA-AES128-SHA256
 0.98% DES-CBC3-SHA
 0.39% AES128-SHA256
 0.26% DHE-RSA-AES128-SHA
 0.07% DHE-RSA-AES128-SHA256
 0.04% DHE-RSA-AES128-GCM-SHA256
 0.03% AES128-GCM-SHA256

Cipher suite usage grouped by key exchange algorithm (and encryption where applicable), for each YubiCloud api* machine:

API 1:

97.40% ECDH
 2.13% RSA-AES
 0.47% RSA-3DES

API 2:

92.79% ECDH
 5.22% RSA-AES
 1.98% RSA-3DES

API 3:

95.18% ECDH
 3.63% RSA-AES
 1.18% RSA-3DES

API 4:

93.64% ECDH
 4.30% DH
 0.00% RSA-AES
 2.06% RSA-3DES

API 5:

92.26% ECDH
 6.65% RSA-AES
 1.09% RSA-3DES

Cipher suite usage grouped by key exchange algorithm (and encryption where applicable), globally across the YubiCloud:

95.59% ECDH
 3.06% RSA-AES
 0.98% RSA-3DES
 0.37% DH

It is worth noting that some connections use 3DES. These are most likely Windows XP machines which did not have any Service Pack installed, otherwise AES support would have been added.

Interestingly enough, Windows XP machines are not something that you want anywhere near close to the Internet, considering that Microsoft is no longer providing security patches and it was originally released 15+ years ago.

For astute readers wondering if 3DES should be disabled, our server preference declares that 3DES cipher suites are the least preferred ones, meaning that newer clients will always use a more modern cipher suite.

Comments are closed.

%d bloggers like this: