Why would a client, connecting to a sever with SSL, use the cipher with the least bits?

Question

I was testing two different Apache2 setup.

In the first case, I used the list offered by http://letsencrypt.org/ which offers free certificate. The list looks like this:

SSLHonorCipherOrder     on
SSLCompression          off
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256
               :ECDHE-ECDSA-AES128-GCM-SHA256
               :ECDHE-RSA-AES256-GCM-SHA384
               :ECDHE-ECDSA-AES256-GCM-SHA384
               :DHE-RSA-AES128-GCM-SHA256
               :DHE-DSS-AES128-GCM-SHA256
               :kEDH+AESGCM
               :ECDHE-RSA-AES128-SHA256
               :ECDHE-ECDSA-AES128-SHA256
               :ECDHE-RSA-AES128-SHA
               :ECDHE-ECDSA-AES128-SHA
               :ECDHE-RSA-AES256-SHA384
               :ECDHE-ECDSA-AES256-SHA384
               :ECDHE-RSA-AES256-SHA
               :ECDHE-ECDSA-AES256-SHA
               :DHE-RSA-AES128-SHA256
               :DHE-RSA-AES128-SHA
               :DHE-DSS-AES128-SHA256
               :DHE-RSA-AES256-SHA256
               :DHE-DSS-AES256-SHA
               :DHE-RSA-AES256-SHA
               :AES128-GCM-SHA256
               :AES256-GCM-SHA384
               :AES128-SHA256
               :AES256-SHA256
               :AES128-SHA
               :AES256-SHA
               :AES
               :CAMELLIA
               :DES-CBC3-SHA
               :!aNULL
               :!eNULL
               :!EXPORT
               :!DES
               :!RC4
               :!MD5
               :!PSK
               :!aECDH
               :!EDH-DSS-DES-CBC3-SHA
               :!EDH-RSA-DES-CBC3-SHA
               :!KRB5-DES-CBC3-SHA

WARNING: The list of cyphers is supposed to be one long line in Apache2, but to make it readable here, I broke it up with one cipher per line.

When I test that list with

https://www.ssllabs.com/ssltest/analyze.html?d=<domain.tld>

I get:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256   (0x9e)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384   (0x9f)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA    (0xc013) ECDH secp256r1  FS  128 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA    (0xc014) ECDH secp256r1  FS  256 (eq. 3072 bits RSA)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   (0x67)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA      (0x33)   DH 2048 bits    FS  128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   (0x6b)   DH 2048 bits    FS  256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA      (0x39)   DH 2048 bits    FS  256
TLS_RSA_WITH_AES_128_GCM_SHA256       (0x9c)                       128
TLS_RSA_WITH_AES_256_GCM_SHA384       (0x9d)                       256
TLS_RSA_WITH_AES_128_CBC_SHA256       (0x3c)                       128
TLS_RSA_WITH_AES_256_CBC_SHA256       (0x3d)                       256
TLS_RSA_WITH_AES_128_CBC_SHA          (0x2f)                       128
TLS_RSA_WITH_AES_256_CBC_SHA          (0x35)                       256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 2048 bits    FS  256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA     (0x84)                       256
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 2048 bits    FS  128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA     (0x41)                       128
TLS_RSA_WITH_3DES_EDE_CBC_SHA         (0xa)                        112

Now, I understand the concept of putting the DHE and ECDHE first. These are clearly marked with "FS" which means Forward Secrecy (i.e. your messages will remain secret in the future even if a hacker can somehow obtain your private key. At least until qubits are a reality.)

What I'm wondering is the column with the numbers "128" then "256". Why would we put a cipher with less encryption bits first? Is the encryption as secure but will be faster because it needs less bits to encrypt the data? Or should we have all the 256 first, then the 128, and at last the 112 (if we are to keep that ugly one...)

Or am I misunderstanding that number altogether and the order is already as good as can be?

---

Later I tested with a setup that I got from doing PCI Compliance check on a server and came up with a setup that generates that list. The setup looks like this:

SSLCipherSuite          HIGH:MEDIUM:!ADH:!MD5:!aNULL:!eNULL:!LOW:!EXP:!RC4

Pretty simple! However, that setup does not support the SSLHonerCipherOrder option. Whether that option is on or not, the order is said to be unspecified by the server (which is probably true.)

In that case, the Qualys SSL Labs website ends up sorting the ciphers as following: all the smallests first (112) and then the largest last (256). Would that be what browsers would do? Trying to get the smallest number of bits to proceed with the encryption? Wouldn't that be the least secure way of transmitting data?

TLS_RSA_WITH_3DES_EDE_CBC_SHA         (0xa)                        112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     (0x16)   DH 2048 bits    FS  112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA   (0xc012) ECDH sect571r1  FS  112 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_128_CBC_SHA          (0x2f)                       128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA      (0x33)   DH 2048 bits    FS  128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA     (0x41)                       128
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 2048 bits    FS  128
TLS_RSA_WITH_SEED_CBC_SHA             (0x96)                       128
TLS_DHE_RSA_WITH_SEED_CBC_SHA         (0x9a)   DH 2048 bits    FS  128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA    (0xc013) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_128_CBC_SHA256       (0x3c)                       128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   (0x67)   DH 2048 bits    FS  128
TLS_RSA_WITH_AES_128_GCM_SHA256       (0x9c)                       128
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256   (0x9e)   DH 2048 bits    FS  128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH sect571r1  FS  128 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_256_CBC_SHA          (0x35)                       256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA      (0x39)   DH 2048 bits    FS  256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA     (0x84)                       256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA    (0xc014) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)
TLS_RSA_WITH_AES_256_CBC_SHA256       (0x3d)                       256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   (0x6b)   DH 2048 bits    FS  256
TLS_RSA_WITH_AES_256_GCM_SHA384       (0x9d)                       256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384   (0x9f)   DH 2048 bits    FS  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH sect571r1  FS  256 (eq. 15360 bits RSA)

Answer 1

You seem to be mistaken about SSLHonorCipherOrder. Doc says "normally the client's preference is used. If this directive is enabled, the server's preference will be used instead." So the option is misnamed, it should be named something like PICK_THE_CIPHER_PER_SERVER'S_ORDERING_AND_DONT_RESPECT_THE_CLIENT'S_ORDERING.

The important information is that default TLS/SSLv3 cipher negotiation doesn't work, as our Apache doc would claim, normally. Well it's as much a "negotiation" as Cuba negotiating with US. RFC says that in the very first message client sends a list of possible ciphers. Is it an ordered list? It depends on the server, really. One of ciphers is picked by the server. The server decides. The client can only proceed or restart the whole session. Server doesn't ever show its full list, so in no case it allows client to pick anything from it.

The SSLHonorCipherOrder off (normal Apache) is when the server abdicates, starts treating it's own SSLCipherSuite as an unordered list, and instead treats client's proposition as an authoritative ordered list: the first supported cipher would be blindly used. With on, server treats client's proposition as unordered. The server's preference (always internal) is SSLCipherSuite list.

Thus ssllabs test without SSLHonorCipherOrder is useless as it simply says what is ssllabs' preferred order. What you said the option was unsupported with HIGH:MEDIUM:etc is not true: it works beautifully with my sites and ssllabs does show HIGH suites first. The report shows exactly the same cipher order as the server command openssl ciphers 'HIGH:MEDIUM:etcxxx', unsurprisingly.

And a last point. "Weak-Strong-Strong" cipher suites don't make sense, they are unbalanced. RSA 2048 is weak. Wikipedia says it is estimated at 112 bits. And if RSA is broken, bye bye https, hello man-in-the-middle. So it makes little sense to join AES256 which is ridiculously strong, with a very weak RSA 2048. It's a waste of CPU, really. We should start trashing the RSA certificates and re-issue our certificates as ECDSA as soon as possible, so we could have our first processor friendly, well balanced, secure cipher suite (and I mean ECDHE-ECDSA-AES128-GCM-SHA256).

Answer 2

I think your question can be reduced to these questions:

• Does it make sense for the server to prefer ciphers which less bits?
  It makes sense for a server to prefer ciphers use less resources on the server side. Insofar it makes sense to prefer ciphers with less bits if these are faster as long as these are secure enough. But note that the strength and performance of ciphers do not depend solely on the bits but also on the algorithm.
• Do clients prefer ciphers with less bits too, i.e. in case the servers honors the cipher order of the client?
  This depends on the client. SSLLabs has more information about the behavior of specific clients. There you can see for example that currently both Chrome and Firefox prefer AES with 128 bit before 256 bit while Edge does the opposite.