There are two cases for changing SSL/TLS cipher settings

October 17, 2013

I've recently been reading a discussion about TLS cipher settings for a program. The suggestion was made that there should be some sort of abstract high level setting for this, one that would be all that most people should ever need (partly this was proposed on the entirely sensible grounds that TLS cipher settings are insanely difficult to get right unless you're a real expert). While this is perhaps a good idea in theory, I'm not sure it's going to work in practice. You see, in practice I see two reasons to change TLS cipher settings.

We can see the first reason by asking why you wouldn't just always set the cipher settings to the 'high security' setting and be done with it. Well, I can't give you a concrete reason why not, but in general any reasons why you might not want to do that are the high level settings you'd want to control. Perhaps you need to use less CPU, perhaps you need some general TLS option that impacts security, perhaps you need to be compatible with older or odder clients. But the meta-point here is that the high level options chosen need to be meaningful ones and as a result, determining what they should be will take real work and real domain expertise (not just in TLS in general but in the tradeoffs that are commonly seen in the field). You can't just throw something like 'high', 'medium', and 'low' settings into your program and think you're done; at a minimum those are the wrong names for whatever the real choices being made are.

The second reason to set ciphers is to deal with new attacks on TLS ciphers or your TLS implementation (or both at once, if you're unlucky). While this year has not been a good one for TLS, this sort of thing can happen any time and when it does, some people will want to mitigate it in the short term (or need to). There is no real option for this other than direct control over TLS ciphers and other TLS options; no high level option will do it because no high level option can foresee the future.

(At some later point the program can be updated either to always be secure or, if there are tradeoffs involved, to have a high level option for it. However in realistic situations this update will take literally years to make it out into the field; before then, your options are low level TLS control or nothing.)

PS: a corollary of the second reason is when TLS best practices change between when your program was written and when you are using it. Again, high level options can't really help you because the program would have had to anticipate the future.

Written on 17 October 2013.
« Disused addresses and the impact of spam
ZFS uberblock rollback and the top level metadata change rate »

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

Last modified: Thu Oct 17 01:17:17 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.