On the Security Ratchet
The IETF uses Jabber for instant messaging during working group meetings, as does the IAB for its own teleconferences and meetings. Since I didn’t really feel like shopping around for a Jabber account, and XMPP integration with Google Talk shut down in the middle of the decade, I decided a few years ago to run my own server, which I pretty much only use for connecting to IETF conference rooms and for chatting with IETF folks as a backchannel during meetings. Prosody is a pretty nice piece of software, so after a little work to get it up and running (IIRC, most of this was getting used to the fact that the configuration files are written in Lua) it’s basically stayed up flawlessly since then.
Until I ran apt update && apt upgrade last week to upgrade the Debian testing
box on which it was running. And then it didn’t.
Okay, troubleshooting things is fun – indeed, the whole point of running Debian testing is to have fun troubleshooting things. So, let’s have a look. Prosody fails to start because it doesn’t like my certificate. Okay, I guess I don’t like my certificate, either – it’s an old StartSSL cert (for which read dodgy), which I only failed to replace with a LetsEncrypt cert due to problems with some clients not trusting the LetsEncrypt root a while back.
Point to the new cert, delete the old one, systemctl restart prosody and we’re
up and running again… but wait, I can talk to some people but not to others,
and attempts to join any chat room on jabber.ietf.org fail. Okay, let’s go
have a look at the log. A little grepping about shows that connections to
jabber.ietf.org fail with dh key too small.
Well, okay, thanks, but that wasn’t a problem until the upgrade. Nothing changed
in the Prosody defaults configuring ciphers, so why break now? Oh, right.
Prosody uses OpenSSL, and OpenSSL has system-wide as well as
application-provided configuration (in a file whose opening header helpfully, but a
little misleadingly, explains “this is mostly being used for generation of
certificate requests”). A little more poking about yields this line in
/etc/ssl/openssl.cnf:
CipherString = DEFAULT@SECLEVEL=2
Sure enough, Debian upgraded the default OpenSSL system security level to 2
(security levels being, ahem, clearly documented in the manpage for
SSL_CTX_get_security_level()),
upping the minimum security level to 112-bit equivalent, and causing any
connection that can’t negotiate at least that to fail. Since I hadn’t changed my
OpenSSL system-wide configuration on this box, apt happily updated it. And the
result was an interoperability failure with one of an XMPP server that’s kind of
the whole reason I run Jabber, caused by one committer on a large open-source
project faithfully following the Internet security community’s best current
advice on the configuration of cryptographic protocols.
How’d I fix it? Easy:
CipherString = DEFAULT@SECLEVEL=1
I get it. Ratcheting security up on the Internet is important. 80 bits isn’t enough today against a well-motivated attacker, and as available compute power continues to scale, the amount of motivation required to break the confidentiality or integrity (in this case, of my connections to other Jabber servers) will only go down. But between 80 bit security and a broken service, I know what I choose. If we move the ratchet too quickly, we risk being ignored by people who just want things to work. I’m ignoring us, and I’m one of us.
(Indeed, I’m apparently not the only one for whom this broke something important: the change has already been backed out on Debian unstable.)
