17

If a client presents a higher cipher suite during ClientHello yet eventually negotiates a lower strength cipher suite within the same protocol version, though a higher cipher suite is available on both client and server, who is responsible?

According to How does SSL/TLS work? it is ServerHello which ultimately decides the cipher suite.

From that post:

To remember: the client suggests but the server chooses. The cipher suite is in the hands of the server. Courteous servers are supposed to follow the preferences of the client (if possible), but they can do otherwise and some actually do (e.g. as part of protection against BEAST).

To understand this question better, an example is provided below.

Example With Firefox:

There is a Client (A) and a Server (B).

Client (A) is a Firefox version 65 browser.

Server (B) is a web server serving a site over https.

Behavior:

Connections to Server (B) @ site.server.com are being negotiated from a stronger TLS 1.2 cipher suite to a less strong TLS 1.2 cipher suite, even when a stronger cipher suite is available on both the client and the server. This behavior is confirmed on Firefox 65.

Steps to Reproduce:

  1. Disable TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and all other weaker cipher suites in Firefox then reload site.server.com The site will load with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

  2. Enable TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 while leaving TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 enabled as well then reload site.server.com.

The weaker cipher suite will be chosen.

In this scenario, who was responsible? ClientHello or ServerHello

RealDrGordonFreeman
  • 357
  • 2
  • 12

3 Answers3

24

The client sends only what ciphers it supports in the order of their preference. The server then selects one of these ciphers - which means only the server ultimately decides which cipher gets used.

It is fully up to the server which cipher suite gets selected from the offered ones, i.e. the server might take the client preferences in account but might also completely ignore it. In fact, many servers have a configuration option which allows the server to use either the cipher preferred by the client or the cipher preferred by the server.

Faulst
  • 368
  • 2
  • 5
Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • Understood, but in the scenario above, the higher cipher suite is supported by both the client and the server, yet the connection is made with the weaker cipher suite. Both the client and the server can also use the higher cipher suite if the browser does not allow the weaker suite. – RealDrGordonFreeman Feb 16 '19 at 16:47
  • 5
    @RealDrGordonFreeman: The server chooses to not use some "better" cipher but instead chooses to use some "sufficiently secure" cipher - which is perfectly fine. There is no need to use always the "highest" available crypto but it is perfectly fine to use a sufficiently secure crypto. Using SHA384 instead of "only" SHA256 as in your example does not increase the security in practice but costs more computing power and also takes more bandwidth (HMAC is larger). So why waste resources without practical gain? – Steffen Ullrich Feb 16 '19 at 16:53
  • 10
    @RealDrGordonFreeman: Any service which takes security seriously would make sure that the ciphers used are __sufficiently__ secure and that the rest of the infrastructure is secure too. This behavior would be different from some other services which brag about their military security or "my key size is bigger than yours" but fail to properly address essential security measures outside of the ciphers, like web application security. – Steffen Ullrich Feb 16 '19 at 17:54
  • 3
    @SteffenUllrich is right. If you don't trust a ciphersuite, do not introduce it in your ClientHello. If the server is not pleased with your decision, then you'll get an error and you don't use the service. Simple and fair. – Esa Jokinen Feb 16 '19 at 20:18
  • 1
    @RealDrGordonFreeman, depending on the server software, the cipher order can be explicitly set in the servers configuration. For example, I may choose to prefer ECDHE+AES128 over RSA+AES256 for performance reasons. But being a human-settable file, I could easily make a mistake and put a weaker cipher at the top of the list; the client would simply obey. This might just be an oddly configured server. – John Deters Feb 16 '19 at 21:22
  • 3
    @SteffenUllrich SHA-384 (which is just SHA-512 with a different IV and truncated to 384 bits) is likely to take _less_ computing power than SHA-256 on 64-bit systems since it uses 64-bit words instead of 32-bit words. It also has a block size twice as large while not doubling the number of rounds (SHA-256 uses 64 rounds and SHA-512 uses 80). You're probably right that the HMAC would be larger though. – forest Feb 17 '19 at 09:46
  • 2
    @forest: good point with the performance of the hashes. – Steffen Ullrich Feb 17 '19 at 11:21
0

The reason why the server chooses cipher suites is because of the authentication algorithm which is based on the server certificate. While for weaker cipher suites selection sometimes server has some attributes to prefer server cipher order over client. For example "useServerCipherSuitesOrder" in tomcat forces server cipher suite order.

schroeder
  • 125,553
  • 55
  • 289
  • 326
Raghu Ram
  • 1
  • What authentication algorithm are you talking about? – schroeder Nov 11 '21 at 13:08
  • The pre-master key will be encrypted by the public key, which is based on the server certificate. If this is an RSA certificate, then the authentication mechanism uses an RSA public key. The cipher suite is partially determined. – Raghu Ram Nov 11 '21 at 13:57
-3

The server should honor the client's Cipher Suite preference. Citing the TLS 1.2 RFC 5246:

The cipher suite list, passed from the client to the server in the ClientHello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). ...The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection.

So ultimately the server decides. See e.g. Apache httpd mod_ssl directive, which

if enabled, the server's preference will be used.

When in doubt I suggest recording the handshake (pcap) and inspecting the hello messages.

Community
  • 1
stuchl4n3k
  • 138
  • 3
  • 8
    I don't agree that the server should honor the clients preference. What you cite says only that the client tells the server the preference. It then says that the server should select one of the ciphers offered by the client. But nothing there says that the server should honor the clients preference when selecting a cipher. In fact, it is very common that servers prefer their own order. – Steffen Ullrich Feb 16 '19 at 16:33
  • 4
    The server is responsible for choosing, period. The standard says the client can send the list in preferential order, but it doesn’t say anything about the server taking the client’s preferences into account. It only says that it must choose from the client’s presented list. Servers are configured by admins for both performance and security reasons, neither of which the client knows anything about. Only if the admins literally don’t care about their servers should they respect the clients’s preferences. – John Deters Feb 16 '19 at 21:31