Image of the glider from the Game of Life by John Conway
Skip to content

OFTC, SSL, NickServ and Irssi

I'm on a bit of an IRC kick with the blogging lately, mainly because it seems I'm usually fine tuning my settings, and I like to share what I find. Hopefully, someone finds these posts useful. For today's post, I've picked setting up an SSL connection on OFTC and securely identifying to NickServ when connecting. with Irssi. Before beginning, it should be noted that the instructions for this tutorial can also be found on the OFTC site. I'm merely taking that tutorial, and posting only the Irssi instructions here, more or less. However, if you use another client, you should read over that tutorial instead.

Generating an OpenSSL Certificate
OFTC runs a forked version of hyperion-ircd that they call oftc-hybrid. It's a patched version of hyperion that Freenode was running on their servers before the switch to ircd-seven. It supports IPV6, SSL, and CertFP with NickServ, that I'll cover later in this post.

Before connecting to OFTC, we want to generate an OpenSSL certificate. This certificate will be used for authenticating to NickServ, and really isn't related to setting up an SSL connection to OFTC. However, when you connect, you will be presenting OFTC with the generated certificate, and at that point, you will be able to add it to NickServ, because it's been presented. If you already have your own personal certificate you want to use, then you can skip this step, and move on to connecting with SSL.

I'm going to assume you have OpenSSL installed. If you're running any modern Unix-like operating system, such as GNU/Linux or one of the BSDs, chances are very high that it's been installed by default. If not, install it, and continue with the rest of the post.

In this step, we're going to generate our own self-signed personal OpenSSL certificate. So, fire up a terminal, type in the command below, and follow the on-screen instructions. The values you put here do not matter to OFTC in the least, so fill them in any way you wish. In my case, I'll fill in the data for my personal certificate, but you fill in the values as you see fit. Replace "nick.key" and "nick.crt" with your IRC nick that you use for this connection.

cd ~/.irssi
mkdir certs
cd certs
openssl req -nodes -newkey rsa:2048 -keyout nick.key -x509 -days 365 -out nick.crt
Generating a 2048 bit RSA private key
writing new private key to 'nick.key'
Country Name (2 letter code) [US]:US
State or Province Name (full name) [Texas]:Utah
Locality Name (eg, city) [San Antonio]:Ogden
Organization Name (eg, company) [Stealth3]:eightyeight
Organizational Unit Name (eg, section) [ISP]:OFTC
Common Name (eg, YOUR name) []:Aaron Toponce
Email Address []

Now, if you look, you'll have two newly generated files: "nick.key", which is your private key and "nick.crt" which is your public self-signed certificate. Because "nick.key" is your private key, you want to guard it appropriately. Its permissions should be modified to only be readable (and maybe even writable) by you, and you alone. Also, because we have both the private and public key set, let's go ahead and combine the files into one PEM file that we'll present to NickServ when connecting:

cat nick.crt nick.key > nick.pem
chmod 0400 nick.key nick.pem

Connecting with SSL
At this point, we are ready to connect to OFTC, and present our certificate to the server. So, fire up Irssi if you haven't already:

irssi -!

Now that we're in Irssi, we want to setup our SSL connections to OFTC. You should have ~/.irssi/certs/nick.pem available to send.

We will need to retrieve the CA certificate for verifying the server certificate. I personally like to put all my CA certificates in my certificates store, and this is where I deviate a little from the tutorial on the OFTC site. OFTC has their certificate signed by Software in the Public Interest, so we'll need their CA certificate. Fortunately, Debian, Ubuntu, and many other GNU/Linux operating systems provide this certificate for us, so we just need to identify the location of the certificate, and plug that into Irssi. If you don't have that certificate, refer to the tutorial on the OFTC site for obtaining it and installing it on your system.

So, with Irssi waiting for our command, let's tell it out to connect to OFTC:

/network add oftc
/server add -auto -ssl -ssl_cert ~/.irssi/certs/nick.pem -ssl_verify -ssl_cafile /etc/ssl/certs/spi-cacert-2008.pem -network oftc 6697
/connect oftc

When we successfully connect, we should see that OFTC has accepted our self-signed certificate in the MOTD, and it should also show that we are connected securely to the network with SSL:

16:20 [oftc] Irssi: Looking up
16:20 [oftc] Irssi: Connecting to [] port 6697
16:20 [oftc] Irssi: Connection to established
16:20 [oftc] []: *** Looking up your hostname...
16:20 [oftc] []: *** Checking Ident
16:20 [oftc] []: *** Found your hostname
16:20 [oftc] []: *** No Ident response
16:20 [oftc] []: *** Connected securely via TLSv1 AES256-SHA-256
16:20 [oftc] []: *** Your client certificate fingerprint is 4A5463CE416649F72818B22945681D28250C1ACA
16:20 [oftc] >>> Welcome to the OFTC Internet Relay Chat Network eightyeight

Sweet! We're connected securely, and OFTC accepted my client certificate by printing the fingerprint for me. If the fingerprint is not displayed, then OFTC has not accepted my certificate, and I need to review the steps outlined above, or on their site.

Authenticating to NickServ with SSL
From here on out, our connection is secured, and we can enjoy the safety that is encrypted packets. So, at this point, we need to register our nick with NickServ, if we haven't already. It should be pointed out that Services has a complete help document provided. Messaging "help" to any of the Services bots will give you a break down of the available commands and their syntax. I would highly recommend becoming familiar with how to use the provided documentation.

/msg NickServ help
04:22 [notice(NickServ!] *** NickServ Help *** 
04:22 [notice(NickServ!] ACCESS: Maintains the nickname ACCESS list.
04:22 [notice(NickServ!] CERT: Maintains the nickname client certificate list.
04:22 [notice(NickServ!] DROP: Releases your nickname for use.
04:22 [notice(NickServ!] ENSLAVE: Enslave a nickname to this master nickname.
04:22 [notice(NickServ!] HELP: Shows this help.
04:22 [notice(NickServ!] IDENTIFY: Identify your nickname.
04:22 [notice(NickServ!] INFO: Get information on a nickname.
04:22 [notice(NickServ!] LINK: Link this nickname to a master nickname.
04:22 [notice(NickServ!] LIST: Shows a list of nicknames matching a specified pattern.
04:22 [notice(NickServ!] RECLAIM: Release your nickname for you to use.
04:22 [notice(NickServ!] REGAIN: Release your nickname for you to use.
04:22 [notice(NickServ!] REGISTER: Registers a nickname for your usage.
04:22 [notice(NickServ!] SENDPASS: Send a password reset request.
04:22 [notice(NickServ!] SET: Set nickname properties.
04:22 [notice(NickServ!] STATUS: Shows the identified status of a nickname
04:22 [notice(NickServ!] UNLINK: Unlink this nickname from a master nickname.
04:22 [notice(NickServ!] *** End of NickServ Help ***

In this case, we're interested in registering and then identifying. The syntax for registering is providing your password and email as arguments. Providing the correct email is key, so should you lose your password and you can no longer authenticate with SSL, you can have NickServ email you your password. So, I would recommend putting in a valid email here, and not some throw away string:

/msg nickserv register password
/msg nickserv identify password

At this point, our nick is registered and we are identified to NickServ. If the nick you're wishing to register is already registered, then you'll either need to pick a different nick, or join #oftc on the network, and see if staff can assign that nick to you. At any event, you must be identified with a valid nick before you can proceed with the next steps.

Now that we are identified to NickServ, we need to add our hostmask to the access list. This is beneficial, so we won't be asked to identify when we connect, which is what we want. So, we need to find our hostmask. This is simple enough by running a /WHOIS on yourself, and identifying your host string. So, it might be something like this:

/WHOIS eightyeight
04:29 [oftc]      nick  | eightyeight 
04:29 [oftc]      host  |
04:29 [oftc]     gecos  | eightyeight
04:29 [oftc]    server  | [Freemont, CA, USA]
04:29 [oftc]      info  | user has identified to services
04:29 [oftc]  hostname  | 
04:29 [oftc]      info  | is connected via SSL (secure link)
04:29 [oftc]      idle  | 0d 0h 1m 48s [signon: Sat Jan 30 16:20:12 2010]

In this case, my host is "". This is what I want to provide to NickServ:

/msg nickserv access add *

Good. Now we're ready to add our self-signed certificate. Remember, when you connected, in the beginning of the MOTD, your certificate fingerprint was displayed. You will want to copy this output and paste it here. You can also use the "openssl" command to get the fingerprint of your cert, you will just need to remove the colons out of the string when providing it to NickServ. In my case, my fingerprint was 4A5463CE416649F72818B22945681D28250C1ACA, so I'm going to add that. Change the string for your fingerprint:

/msg nickserv cert add 4A5463CE416649F72818B22945681D28250C1ACA

That's it! At this point, if you were to connect again (you must /disconnect and then /connect. /reconnect doesn't apply the SSL settings, apparently (BUG?)), you will find that you will automatically identify to NickServ with your cert, and without a password. As you can imagine, this is highly secure. If you are not taking advantage of SSL, then your password can be sniffed on the wire, and your account could be compromised. In this case, we're neglecting the password, and using public key cryptography instead to authenticate. I don't know at this point if a MITM attack would be successful. So, bonus.

To see that it has succeeded, when you connect you should see the following at the end of the MOTD:

05:14 [oftc2] >>> You have set user mode +i
05:14 [oftc2] >>> You have set user mode +R
05:14 [oftc2] [notice(NickServ!] You are connected using SSL and have provided a matching client certificate
05:14 [oftc2] [notice(NickServ!] for nickname eightyeight. You have been automatically identified.

Congratulations! You are now connected securely to OFTC via SSL and you have identified to NickServ successfully with your self-signed certificate. The major benefits of this method, is you can ditch any client-side identification scripts, which is always a bonus. Further, your packets are now encrypted between you and the OFTC servers. OFTC also utilizes server-to-server encryption, so if you're physically connected to a server in the United States, and someone you're in private message with is physically connected to a server in Europe, not a single plaintext packet is sent on the wire between your client and his (assuming he's connected via SSL as well).

A final not on SSL connections, is your computer clock that you are running Irssi on needs to be accurate. It would be recommended to use NTP to keep your clock in sync with Internet time servers. If your clock is too far off, you won't be able to negotiate the OpenSSL handshake, and as a result, not be able to take advantage of the encrypted traffic. Also, OpenSSL certificates need to be valid. If your certificate expires, then you will not be able to present it to the server, and as a result, not be able to authenticate to NickServ. The dates on expiration are up to you, but validity is important. You can see the dates of your certificate with the following command:

openssl x509 -noout -in nick.pem -dates

Enjoy the security.

{ 2 } Comments

  1. phaleon using Firefox 3.6.13 on Gentoo | February 27, 2011 at 4:48 pm | Permalink

    Thank's a lot

    I am now able to have a more secure connection with irssi.

    I will try that on freenode as well ;-)

  2. foo using Firefox 12.0 on GNU/Linux 64 bits | May 13, 2012 at 11:01 am | Permalink


{ 1 } Trackback

  1. [...] NickServ’s certfp module. (see /msg nickserv help cert and <BETTER, FREENODE SPECIFIC URL HERE>) [...]

Post a Comment

Your email is never published nor shared.

Switch to our mobile site