2021-05-31
It'd be useful if TLS libraries had better and more detailed error messages
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.)
I've come to like date-based names for log rotation
One of the divides in Linux distributions is how they set up logrotate, especially including how they have logrotate name the 'rotated' copies of logs. Ubuntu (and I assume Debian) use the traditional approach of numbered old log files, where the most recently rotated log file has a .0 suffix, the next most recent has a .1 suffix, and so on back to however many versions you want to keep. A while back, Red Hat Enterprise and thus Fedora switched to date-based naming, where the suffix is based on the day that the log was rolled and you get names like 'cron-20210530'.
(Both naming schemes often then compress the rotated logs. Sometimes the most recently rotated log, the '.0' log, is left uncompressed, partly in case something is still writing to it.)
This is usually set in /etc/logrotate.conf as a global option.
As covered in the manpage, number
based rotation is the default and to get date based names you set
at least dateext and possibly some of the other date-related
options. Conveniently, logrotate properly names logs you rotate
hourly instead of daily or weekly without you have to mess around
with dateformat.
(This is what logrotate really should do, but as a system administrator I'm often a cynic about whether programs will do the better but somewhat more difficult thing or throw it in your lap.)
At first I didn't like what Red Hat and Fedora had done with the switch to date-based extensions, primarily because it made it harder to look at the most recently rotated full log file, or more broadly yesterday's log file or last week's log file. In a number based version that's always '.0' (and then '.1' and so on), but in the date based version it has a variable name. However, over time I've come to appreciate the good sides of the date based naming. In date based naming a given rotated logfile always has the same name so you can come back to it later, instead of getting constantly renumbered over time, and it's easy to know what rotated log file to look at to search over a particular date range.
Periodically I know that something happened, say, last Thursday, and I
need to look at logs for it. In the number based naming I need to use
'ls -lt' (and possibly a calendar) to work out what file to look at,
and if I need to re-check it tomorrow I'll have to go through the whole
process again. With date based naming, it's right there and it's always
got the same name. Given a long enough retention time, I can write up a
simple description of how I searched for some information, and then in a
few days or a week or two, other people can still readily reproduce it.
They could do the same thing with number based naming, but it would need
the extra step of 'first find the log file for ...'.
I'm not going to propose we switch our regular Ubuntu servers to date based logging. We're used to the current state of affairs and there are advantages to following the distribution's standard. But someday we're going to replace our current CentOS based central syslog server with an Ubuntu based one (because of CentOS developments, also), and when we do I'm definitely going to advocate for setting it up with date-based log rotation.