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
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
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
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
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
$ 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 220.127.116.11
ns1.gratisdns.dk. 36319 IN AAAA 2a02:9d0:3002:1::2
ns2.gratisdns.dk. 25447 IN A 18.104.22.168
ns3.gratisdns.dk. 31182 IN A 22.214.171.124
ns3.gratisdns.dk. 28269 IN AAAA 2001:678:5::6
ns4.gratisdns.dk. 31182 IN A 126.96.36.199
ns4.gratisdns.dk. 28269 IN AAAA 2a01:558:4000::3
ns5.gratisdns.dk. 25447 IN A 188.8.131.52
ns5.gratisdns.dk. 28269 IN AAAA 2001:6f8:3ad::1
;; Query time: 55 msec
;; SERVER: 184.108.40.206#53(220.127.116.11)
;; 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
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
<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
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
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
$ 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
Building with DANE support ....... : yes
Otherwise you should take a look at the
config.log file and look for places
libval is mentioned and figure out why it doesn’t find the library
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
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
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.