Perhaps you no longer want to force a server-preferred TLS cipher order on clients

January 16, 2019

To simplify a great deal, when you set up a TLS connection one of the things that happens in the TLS handshake is that the client sends the server a list of the cipher suites it supports in preference order, and then the server picks which one to use. One of the questions when configuring a TLS server is whether you will tell the server to respect the client's preference order or whether you will override it and use the server's preference order. Most TLS configuration resources, such as Mozilla's guidelines, will implicitly tell you to prefer the server's preference order instead of the client's.

(I say 'implicitly' here because the Mozilla discussion doesn't explicitly talk about it, but the Mozilla configuration generator consistently picks server options to prefer the server's order.)

In the original world where I learned 'always prefer the server's cipher order', the server was almost always more up to date and better curated than clients were. You might have all sorts of old web browsers and so on calling in, with all sorts of questionable cipher ordering choices, and you mostly didn't trust them to be doing a good job of modern TLS. Forcing everyone to use the order from your server fixed all of this, and it put the situation under your control; you could make sure that every client got the strongest cipher that it supported.

That doesn't describe today's world, which is different in at least two important ways. First, today many browsers update every six weeks or so, which is probably far more often than most people are re-checking their TLS best practices (certainly it's far more frequently than we are). As a result, it's easy for browsers to be the more up to date party on TLS best practices. Second, browsers are running on increasingly varied hardware where different ciphers may have quite different performance and power characteristics. An AES GCM cipher is probably the fastest on x86 hardware (it can make a dramatic difference), but may not be the best on, say, ARM based devices such as mobile phones and tablets (and it depends on what CPUs those have, too, since people use a wide variety of ARM cores, although by now all of them may be modern enough to have ARMv8-A AES-NI crypto instructions).

If you're going to consistently stay up to date on the latest TLS developments and always carefully curate your TLS cipher list and order, as Mozilla is, then I think it still potentially makes sense to prefer your server's cipher order. But the more I think about it, the more I'm not sure it makes sense for most people to try to do this. Given that I'm not a TLS expert and I'm not going to spend the time to constantly keep on top of this, it feels like perhaps once we let Mozilla restrict our configuration to ciphers that are all strong enough, we should let clients pick the one they think is best for them. The result is unlikely to do anything much to security and it may help clients perform better.

(If you're CPU-constrained on the server, then you certainly want to pick the cheapest cipher for you and never mind what the clients would like. But again, this is probably not most people's situation.)

PS: As you might guess, the trigger for this thought was looking at a server TLS configuration that we probably haven't touched for four years, and perhaps more. In theory perhaps we should schedule periodic re-examinations and updates of our TLS configurations; in practice we're unlikely to actually do that, so I'm starting to think that the more hands-off they are, the better.


Comments on this page:

Configure your server/s to get the highest grade you can at Qualys' SSL Labs:

:)

If I were fundamentally interested in being accessible to as many clients as possible, I would set security requirements low and get as much backwards-compatibility as I could. (There could easily be external requirements like PCI compliance if I took credit card information.)

If I were fundamentally interested in providing the safest service possible, I would keep my servers set to the most recent standards -- at this point in time, TLS 1.2 and 1.3 only -- and a nice tight group of ciphers.

As always, the requirement is to know your audience.

Server cipher order is obsolete anyway. IIRC, there was an attack on CBC modes, and the workaround was to force the only stream cipher available… RC4. Which had a worrying number of cracks in it, even at the time, but it was the least-bad option.

But your point stands; if you're tightly managing your TLS configuration, that creates a maintenance burden as the landscape changes.

(My frustration with OpenSSL has always been that they enable the kitchen sink by default, forcing everyone to configure it explicitly to turn off export, null, anonymous, etc. options. Life would be a lot easier if we could trust our security libraries to provide a basic amount of security.)

By cks at 2019-01-16 09:20:38:

The ciphers and TLS versions you offer are more or less independent of whether or not you force the clients to accept the server's cipher order. You can (and should) restrict the TLS versions and cipher choices even if you let clients use whichever one of them they like.

(In an ideal world, servers or default setups would come with sensible defaults for this even if the TLS library doesn't, but this is not an ideal world.)

But this does raise a good point, which is that going with the client order likely works best if you have a restricted cipher list, instead of an expanded one with older, weaker ciphers that you're including for client compatibility. However, even there I suspect that most clients will do fine; they may support old ciphers for compatibility with old servers, but they're unlikely to prefer them. The clients that will actually prefer them are probably the ones that don't have anything better. I am pretty sure that the days when clients supported good ciphers but listed terrible ones first are long over.

Written on 16 January 2019.
« Why your fresh new memory pages are zero-filled
Why C uninitialized global variables have an initial value of zero »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 16 01:11:18 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.