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

TLS 1.3 Hybrid Key Exchange using X25519Kyber768 / ML-KEM

A quick description of what a TLS 1.3 Hybrid Key Exchange using X25519Kyber768 / ML-KEM looks like in practice.

via Signs of Triviality October 31, 2024

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

Wealth = Have ÷ Need

Not a new idea, but just another visualization and reminder. Wealth, feeling like you have plenty, is an equation. Wealth = Have ÷ Need If you have nothing, then focus on having some. Once you have some, the easiest way to increase your wealth is to decrease …

via Derek Sivers blog September 27, 2024

Generated by openring