A couple of weeks ago, I had a discussion with some of the Quakenet coders on how to add SSL support to their IRC daemon, but the discussion ended up being about the false sense of security that SSL potentially can give to the user. The Quakenet hackers have an interesting article online about their thoughts on the matter and while I do understand their points, I do not agree with it being a good enough reason to completely avoid SSL on your IRC network.
We quickly changed the discussion to be about how the IRC clients should be able to verify that the SSL certificate, received from the server, is not a malicious certificate from someone doing MITM attacks. This was not the discussion I had hoped for, but nevertheless, it was an interesting discussion to participate in and made me spend a few days thinking about their concerns.
Sadly, as it is today, some IRC clients, including Irssi, only do full SSL certificate validation as an opt-in option (via the
-ssl_verify option for
/connect in Irssi’s case) rather than having it as an opt-out option, which would be ideal. This is simply because people in the IRC community have historically not wanted to spend money on certificates from the so called “trusted” Certificate Authorities like we have seen on the web. Changing this from opt-in to opt-out is something that I would like to see happen, but it is not something that is going to be easy. We saw how many web sites got a “proper” certificate after the Mozilla guys made it slightly harder to actually mark a self-signed certificate as trusted. This was at first a very annoying move, but these days we rarely see self signed certificates when we browse around the web.
A few days after the discussion on IRC, I was having dinner at Thomas’s place and I mentioned the discussion with the Quakenet hackers. Thomas knows a lot about security, privacy and DNS, and he is an avid Quakenet user, so it appeared more than obvious to take the discussion with him and hear what his take to the problem was. His suggestion was to take a look at DNSSEC and DANE and see if that could be used as a possible solution.
Luckily for me, it was exactly what I was looking for.
A few days after the dinner conversation, I pushed a patch to Irssi’s source code repository that enabled support for DANE validation of SSL certificates.
Let’s have a look at how DANE works. This will hopefully give you enough knowledge to understand the basics of what is going on. I will document how to compile Irssi with DANE support enabled and test whether it works or not.
What is DANE?
DANE is an acronym for “DNS-Based Authentication of Named Entities” and comes with a protocol named TLSA. DANE is an internet standard and you can read the full technical specification of DANE in RFC6698, but hopefully, this article will give you an introduction to get started using DANE for your IRC servers right away. The concepts are totally protocol agnostic so this will work for other protocols than IRC as well, but it does require modification to the client software to work.
DANE is a simple way of storing information about a certificate in the DNS system. Adding DNSSEC on top of the cake, gives you a very powerful way of validating certificates where the client relies on a trusted source (their ISP’s DNS server and DNSSEC) validating the information from the possibly eavesdropped IRC server.
DANE is implemented as a new DNS resource record named TLSA. You can see an example of such record here from our test IRC server linked to the IRCsource IRC network:
$ dig TLSA _6697._tcp.ircsource.baconsvin.org
; <<>> DiG 9.8.3-P1 <<>> TLSA _6697._tcp.ircsource.baconsvin.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38406
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9
;; QUESTION SECTION:
;_6697._tcp.ircsource.baconsvin.org. IN TLSA
;; ANSWER SECTION:
_6697._tcp.ircsource.baconsvin.org. 3358 IN TLSA 3 0 1 9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94
;; AUTHORITY SECTION:
baconsvin.org. 50607 IN NS ns1.gratisdns.dk.
baconsvin.org. 50607 IN NS ns5.gratisdns.dk.
baconsvin.org. 50607 IN NS ns3.gratisdns.dk.
baconsvin.org. 50607 IN NS ns2.gratisdns.dk.
baconsvin.org. 50607 IN NS ns4.gratisdns.dk.
;; ADDITIONAL SECTION:
ns1.gratisdns.dk. 7417 IN A 184.108.40.206
ns1.gratisdns.dk. 36319 IN AAAA 2a02:9d0:3002:1::2
ns2.gratisdns.dk. 25447 IN A 220.127.116.11
ns3.gratisdns.dk. 31182 IN A 18.104.22.168
ns3.gratisdns.dk. 28269 IN AAAA 2001:678:5::6
ns4.gratisdns.dk. 31182 IN A 22.214.171.124
ns4.gratisdns.dk. 28269 IN AAAA 2a01:558:4000::3
ns5.gratisdns.dk. 25447 IN A 126.96.36.199
ns5.gratisdns.dk. 28269 IN AAAA 2001:6f8:3ad::1
;; Query time: 55 msec
;; SERVER: 188.8.131.52#53(184.108.40.206)
;; WHEN: Sat Aug 10 13:16:23 2013
;; MSG SIZE rcvd: 393
Note: If your version of
dig doesn’t recognize the
TLSA type, you can easily replace it with
TYPE52 like this:
dig _6697._tcp.ircsource.baconsvin.org TYPE52.
Notice how the port, 6697, and protocol, TCP, is part of the DNS query. This will be familiar for people who have worked with SRV DNS records.
The interesting part of the output is the answer section where you see the following:
3 0 1 9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94
What does all of this mean?
Let’s start out by looking at the format. The format for a TLSA reply is as following:
<certificate usage> <selector> <matching type> <certificate association data>
This means that our certificate usage field is
3, our selector is
0 and our matching type is
1. The associated data is the string
It is important to understand the semantics of these fields, because they will dictate how and if the client is going to do further validation of the certificate once the client has received it from the IRC daemon.
3 0 1 means that we are using a self-signed certificate and we will rely on DANE for validating the certificate only (3); that we are using the full certificate and not just the SubjectPublicKeyInfo part (0) and we will be using a hexadecimal encoded SHA256 hash of the DER-encoded certificate (1).
To fully understand the various options available, I suggest you take a look at RFC 6698 section 2.1.
Enable DANE Support for your IRC Server
The first step you will have to take is to ensure that whoever runs your DNS servers supports both DNSSEC and TLSA records. In Denmark, a lot of users are using the free DNS hosting provider GratisDNS. GratisDNS supports both DNSSEC and TLSA records which makes setting this up a lot easier.
Sadly, GratisDNS’ interface is currently only available in Danish, so you might have to look for other solutions available online.
Once you have a DNS provider that supports DNSSEC and TLSA records, it is fairly easy to create the records. In our example, the following assumptions are made:
You already have an IRC daemon running with SSL enabled on port 6697 and you have verified that it actually works as expected.
Your certificate is self-signed, so you would like to rely on DANE support only for the validation. This means that the user will not see any self-signed certificate errors when connecting with certificate validation enabled.
We will create a record using a SHA-256 hash of the certificate data. Feel free to use something stronger, if you are more crypto paranoid than I am.
This means that our TLSA record will end up looking something similar to this:
_6697._tcp.irc.example.org TLSA 3 0 1 <SHA-256 hash of the certificate data>
This is basically going to be a description of the exact same setup that I am using for
To find the SHA-256 value of your certificate, start by logging onto the server running the IRC daemon and find the directory that contains your certificate files. We are then going to find the SHA-256 value of the DER representation of our certificate:
$ openssl x509 -in ircsource.baconsvin.org.pem -outform DER | sha256sum
This is the value we will be using in our final TLSA record, which now looks like the following:
_6697._tcp.irc.example.net TLSA 3 0 1 9b954a014881108a9058db80020909ffd8b4c44c6f41c8796b3a1ea43a444b94
Once you have added this record to your DNS zones, it is now time to actually test whether it works as expected.
This part is tested on FreeBSD 9.2-PRERELEASE. Hopefully, it works for other people as well. Feel free to report any issues you may experience.
dnsval tarball from its download page. This is quite new software so I haven’t run into many distributions that have packages available, so we will assume that we have to compile it ourselves.
$ mkdir dane
$ cd dane
$ fetch http://www.dnssec-tools.org/download/dnsval-2.0.tar.gz
$ tar zxfv dnsval-2.0.tar.gz
$ cd dnsval-2.0
$ ./configure --prefix=/usr/local
$ sudo make install
Next we will download the Irssi source code from the Git repository. We start by cloning the repository into our newly created
$ cd dane
$ git clone git://git.irssi.org/irssi
$ cd irssi
We bootstrap the build system:
$ sh autogen.sh
We configure our test Irssi client:
$ CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure --enable-dane --with-perl=no
Make sure that somewhere near the end of the output of the
configure script contains:
Building with DANE support ....... : yes
Otherwise you should take a look at the
config.log file and look for places where
libval is mentioned and figure out why it doesn’t find the library correctly.
Fire up your new Irssi client and give it a spin:
$ ./src/fe-text/irssi -!
Try to connect to our test server,
ircsource.baconsvin.org, using DANE:
/connect -ssl -ssl_verify ircsource.baconsvin.org 6697
If everything was done correctly, Irssi will now connect to the server, verify the signature of the certificate using TLSA and allow you to connect without seeing any self-signed certificate errors.
DANE Enabled IRC Servers
Here’s a list of IRC servers that supports DANE. If you are running a public IRC server and would like to see the server added here, feel free to drop me an email at email@example.com with information about the server.
IRCsource is a small network where people with a general interest in IRC hang out together to discuss and test various new concepts and ideas for IRC.
ircsource.baconsvin.org (SSL ports: 6697 and 9999)
I will do my best to maintain this list of servers supporting DANE in the future.
The next step for me is to start securing server-to-server links within the IRC networks with DANE. This will require some modifications to the IRC daemons themselves. I plan on looking into adding support for DANE in a personal feature branch of ircd-ratbox and some of its derivatives.
I am unable to say if DANE support is what the IRC community will be adopting. The IRC community is very conservative in general so time will have to tell.
If you believe you have found a bug in my code or have any troubles setting DANE up for your own IRC server, I will be more than happy to help. Drop me an email and I will take a look at it whenever I have time. Otherwise, feel free to poke me on IRC. My nickname is
ahf and I am available on most of the “larger” IRC networks (EFnet, Freenode, IRCnet and Quakenet).
All of this code will be available in the upcoming Irssi 0.8.16 release, but if you want to test it right away, my suggestion is to follow my guide from above and use Irssi directly from Git.
Hopefully, we will see other IRC client and server hackers implementing DANE support in the nearby future. If you like what you have read here, please help me making this happen by spreading the word about the possibilities available for enhancing the SSL support in IRC clients as well as other SSL based online services.
This is too easily implementable to be ignored.
I would like to thank Thomas Steen Ramussen for being the originator of the idea and setting up the initial DNS server for testing purpose; Peter Larsen for expeditiously implementing TLSA support for GratisDNS; the IRC6.net guys for late night discussions about DANE; Mickey Fischer for testing the Irssi patches on Gentoo Linux with various options enabled and disabled; the DNSSEC-Tools Project for creating the libraries used and finally the rest of the Irssi team for reviewing the patches and coming with recommendations for my code.