It'd be useful if TLS libraries had better and more detailed error messages

May 31, 2021

For my sins, I spent some time today exploring ways to potentially deal with a future TLS issue we're going to have. Part of this involved hand-generating various TLS certificates in an eccentric system I didn't really understand and then trying to use them in a non-HTTPS context. Through much of this process, I kept getting error messages to the effect of, depending on the library that they were coming from:

depth=0, error=unsupported certificate purpose: [...]
x509: certificate specifies an incompatible key usage

The problem with both of these error messages is that they're not specific. They don't tell me what certificate purpose the certificate has that the library considers unsupported, or what is incompatible, or what purpose and key usage either library is actually looking for. The second library doesn't even clearly say what TLS certificate it's reporting an error about; as it happens, there were a chain of three TLS certificates involved, two of which I had just generated and one that was old enough it might be missing things the library now wanted.

Each library knew these things. But for whatever reason, neither prioritized reporting them, opting instead to have what are probably a limited number of fixed and so less informative errors. For obvious reasons, I wish both would generate more detailed and better errors; if they had, I would have found my problem much sooner.

(I happened to have an old, working certificate that my new one was supposed to be just like; dumping their details side by side let me stare at the two long enough to realize that I had accidentally generated a client certificate instead of a server certificate. Without that I might still be lost, knowing that I had done something wrong but not what.)

Generating relatively detailed error messages is harder than generating simple general ones; you either need to dynamically generate messages or have a lot of canned messages. The code may also need to bubble up details to higher level error generation (or decide what's what should be reported on, when there's more than one possible cause). But it's not impossible, and it can help significantly. TLS is enough of a complex and dark area as it is, even without short, low-detail error messages.

There are reasons to be curt when giving errors to other parties, but here both cases were programs reporting to the person running them. For security sensitive code, this is one of the most important time to be clear; otherwise, the traditional 'solution' that many people will take is whatever options are needed to force things to work. Error messages are often your one chance to persuade people to not go on anyway.

(Unhelpful error messages leading to people doing unwise things is not a new issue, for example package verification errors in a now-obsolete package manager. Of course, these days one answer is not to allow people to override cryptography errors, but that's not all that friendly and can invite worse responses.)

Written on 31 May 2021.
« I've come to like date-based names for log rotation
Simple use of Let's Encrypt on OpenBSD is pleasantly straightforward (as of 6.8) »

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

Last modified: Mon May 31 22:04:51 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.