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:

openssl x509 -fingerprint -sha256 -noout -in znc.pem

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, May 2024

Hi! Sadly, I need to start this status update with bad news: SourceHut has decided to terminate my contract. At this time, I’m still in the process of figuring out what I’ll do next. I’ve marked some SourceHut-specific projects as unmaintained, such as sr.ht-…

via emersion May 21, 2024

How 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, 2024

Email DNS Records Cheatsheet

A quick summary of the SMTP related DNS records together with brief examples.

via Signs of Triviality April 12, 2024

Generated by openring