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, April 2024
Hi! The X.Org Foundation results are in, and I’m now officially part of the Board of Directors. I hope I can be of use to the community on more organizational issues! Speaking of which, I’ve spent quite a bit of time dealing with Code of Conduct matters latel…
via emersion April 16, 2024Email DNS Records Cheatsheet
A quick summary of the SMTP related DNS records together with brief examples.
via Signs of Triviality April 12, 2024the best book ever written
I’ve asked my favorite musicians if, when they’re done writing a new song, they feel it’s the best song ever. All of them said yes. I’ve asked my favorite authors if, when they’re done writing a new book, they feel it was the best book ever. All of them said…
via Derek Sivers blog April 12, 2024Generated by openring