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
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, 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, 2024Wealth = 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, 2024Generated by openring