Wrong Assumptions with Irssi
— 506 words — 3 min
Today I connected back to my irc bouncer znc with the terminal irc client irssi. I had the configuration with my self-signed certificate and certificate pinning already figured out in the past, but that configuration file was on a different computer. And I’m currently travelling, so I didn’t have access to it and, more importantly, I did not save the configuration to my dotfiles or anywhere else where I could easily look it up. However, I remember that I had some issues getting it to work, but in the end I got there.
So I had to do it from scratch, but I thought it would be easy because I’ve already done it. So how hard could it be?
Well, turns out, it took me about an hour again because I had a wrong assumption about one configuration option in irssi.
A configuration block in irssi for a network called libera-znc may look like
the following:
{
address = "mybouncer.server.net";
chatnet = "libera-znc";
port = "1234";
passowrd = "znc-user/znc-network-name:znc-user-password";
use_tls = "yes";
tls_verify = "no";
tls_pinned_cert = "12:34:56:78:90:59:0F:28:0F:48:56:FF:51:F9:D4:8C:0B:94:BC:BF:2F:D1:0C:25:D4:E9:AA:BB:CC:DD:EE:FF";
autoconnect = "yes";
}
Most options should be self-explanatory. So, what was my wrong assumption?
My znc server uses a self-signed certificate, so I can’t use the option
tls_verify, because the certificate is self-signed and therefore cannot be
verified by any CA out there, e.g. Let’s Encrypt. Hence, I removed the option
tls_verify from the configuration thinking that this would equal to
tls_verify = "no".
However, I want to make sure that I always connect to my server (and to prevent MITM attacks), so I generated the sha256 fingerprint of the certificate the znc service is using with OpenSSL:
After verifying a thousand times that my generated certificate fingerprint is
actually correct, I took a step back and thought about it again. I tried to
remember what the problem was and I did remember that it was something stupid
and simple. After staring at the configuration for a while, I noticed in
another network configuration the tls_verify = "yes"; option again. That’s
when it hit me. I put tls_verify = "no"; back into my network configuration
block and it just worked.
So, to remember this and to write it down somewhere, I created this short blog post.
I also looked through the irssi documentation and could not find the
documented default value of the option tls_verify. However, when looking
through the changelog, I found
the following bullet point:
-tls_verify is now enabled by default (#1170, an#18, #1309, an#23, #1343, #1351) This may cause an ugly display of notls_verify in the output of /SERVER LIST, even on plain-text connection, on old configs. Kindly remove the “tls_verify = “no”;” entries from your config file manually.
Articles from blogs I follow around the net
Status update, November 2024
Hi all! This month I’ve spent a lot of time triaging Sway and wlroots issues following the Sway 1.10 release. There are a few regressions, some of which are already fixed (thanks to all contributors for sending patches!). Kenny has added support for software-…
via emersion November 22, 2024Dismissed!
Dismissing gives me a quick little lift. “That guy is an idiot!” “That place sucks!” There. Now I feel superior. Now I don’t have to think about it. I don’t even need first-hand experience. I can just echo any complaint I’ve heard. I’ve done this with restaurants…
via Derek Sivers blog November 18, 2024Generated by openring