In order to easily authenticate with IRC networks such as OFTC and Freenode, it is possible to use client TLS certificates (also known as SSL certificates). In fact, it turns out that it's very easy to setup both on irssi and on znc.
Generate your TLS certificate
On a machine with good entropy, run the following command to create a keypair that will last for 10 years:
openssl req -nodes -newkey rsa:2048 -keyout user.pem -x509 -days 3650 -out user.pem -subj "/CN=<your nick>"
Then extract your key fingerprint using this command:
openssl x509 -sha1 -noout -fingerprint -in user.pem | sed -e 's/^.*=//;s/://g'
Share your fingerprints with NickServ
On each IRC network, do this:
/msg NickServ IDENTIFY Password1!
/msg NickServ CERT ADD <your fingerprint>
in order to add your fingerprint to the access control list.
Configure ZNC
To configure znc, start by putting the key in the right place:
cp user.pem ~/.znc/users/<your nick>/networks/oftc/moddata/cert/
and then enable the built-in cert plugin for
each network in ~/.znc/configs/znc.conf
:
<Network oftc>
...
LoadModule = cert
...
</Network>
<Network freenode>
...
LoadModule = cert
...
</Network>
Configure irssi
For irssi, do the same thing but put the cert in ~/.irssi/user.pem
and
then change the OFTC entry in ~/.irssi/config
to look like this:
{
address = "irc.oftc.net";
chatnet = "OFTC";
port = "6697";
use_tls = "yes";
tls_cert = "~/.irssi/user.pem";
tls_verify = "yes";
autoconnect = "yes";
}
and the Freenode one to look like this:
{
address = "chat.freenode.net";
chatnet = "Freenode";
port = "7000";
use_tls = "yes";
tls_cert = "~/.irssi/user.pem";
tls_verify = "yes";
autoconnect = "yes";
}
That's it. That's all you need to replace password authentication with a much stronger alternative.
I used to use this approach myself, but i stopped using it a few years ago, for two reasons:
certificate expiration -- when my registered certificate expires, i still need to update the server with my new certificate. to do that, i need my password. so my password still works, and i still have to retain it and send it to (what i hope is the correct) nickserv service at each cert renewal time. so this doesn't actually remove either my needing to remember/retain/record a password, and it doesn't make my remembered/recorded password less powerful.
client certificate leakage -- in TLS versions 1.2 and earlier (all deployed versions of TLS), the client certificate is exchanged in the clear, during the handshake. (TLS 1.3 will fix this, but it is not yet fully standardized or in deployed production). This means that client cert authentication actually leaks your identity to any passive network observer, whereas password-based authentication to nickserv does not.
This pains me, because i generally strongly prefer pubkey-based authentication over password-based authentication. But in this case, i think it's not enough of a win overall to make the transition.
What do you think about these tradeoffs? Are there mitigating factors that i should know about that makes them less troubling?
Thanks to this discussion, i just opened a bug report on irssi to try to resolve the second issue above by sending client certificates in a renegotiated handshake.
I've tested irssi, and it definitely does leak the user's public certificate to a passive network monitor.
I haven't tested ZNC yet -- If someone wanted to open a similar report for ZNC, i'd appreciate it.
If you want to test to see whether it's dumping traffic, you can do this with tshark:
I don't have a patch to propose for either irssi or ZNC yet, and don't have much time to work on it myself. I'd be happy to see that happen, because it would remove one of the major downsides to using certificates for IRC.