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, June 2024
Hi all! This status update will be shorter than usual because I had a lot less free time for my open-source projects than usual this month. Indeed, I recently joined SNCF Réseau (the company responsible for the French railway infrastructure) to work on OSRD, …
via emersion June 19, 2024Whose CIDR is it anyway?
A look at CIDR block ownership from a RIR-, country-, and organization level. Originally presented at RIPE88.
via Signs of Triviality June 12, 2024How and why to make a /now page on your site
Background I used to wonder what my friend Benny Lewis was doing. He has a website and social media accounts, but neither gave an overview of what he’s doing now. Then I realized some people might wonder the same about me. So in 2015, I made a /now page on my…
via Derek Sivers blog May 18, 2024Generated by openring