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
Dismissed!
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, 2024Status update, October 2024
Hi! This month XDC 2024 took place in Montreal. I wasn’t there in-person, but thanks to the organizers I could still ask questions and attend workshops remotely (thanks!). As usual, XDC has been a great reminder of many things I wanted to do but which got bur…
via emersion October 21, 2024Generated by openring