Improving IRC security step by step
I've been working at UnrealIRCd since 2001 to make IRC more secure. Below I would like to share the journey that IRC has taken so far with regards to deploying SSL/TLS and the way ahead.
Step 1: Make IRC software support SSL
Fortunately this step was completed long ago. All major IRC servers and clients support SSL/TLS nowadays. UnrealIRCd added support for SSL/TLS in the year 2000. On the client side, irssi added support for SSL/TLS in 2002 and mIRC in 2004, just to name two of them.
Step 2: Choose a standard SSL/TLS port
Next problem was choosing on which port SSL/TLS should be provided. In the beginning there was no standard and each IRC network/server had to publish what port users had to use for SSL/TLS. This was settled unofficially by choosing port 6697 by various networks and UnrealIRCd in 2004. Ten years later this practice was made official in RFC7194.
Another option is to use STARTTLS. This allows clients to "upgrade" to SSL/TLS from a regular plaintext IRC port. This was added in 2009 in UnrealIRCd but clients didn't use it. In 2012 the tls IRCv3 extension tried to make it better but as others mentioned implementing it securely on the client side is not straightforward. Bottom line is that nowadays we recommend using dedicated SSL ports.
Step 3: Enable SSL/TLS on servers
Next we need (more) server administrators to enable SSL/TLS on their server. UnrealIRCd has been shipping with an example configuration file that enabled SSL/TLS since 2004. Still, server administrators, using UnrealIRCd or other server software, didn't always compile with OpenSSL support and even then didn't always make SSL/TLS available to users.
Fortunately this is changing quickly. Today, many networks have SSL/TLS port 6697 open for clients.
At UnrealIRCd with the release of 4.0.0 in 2015 we made compiling with OpenSSL (or LibreSSL) no longer optional. Additionally, in February 2017 we started showing warning messages to administrators if they do not have any SSL port open.
Step 4: Move clients over to SSL/TLS
It's nice when servers provide SSL/TLS but it is of little use if clients don't use it. Getting more clients to use SSL/TLS is one of the major challenges today.
While security conscious users may use SSL/TLS, by far the majority of users still use plaintext connections.
Strict Transport Security
An attempt to change this is the Strict Transport Security IRCv3 draft. Once configured by the server administrator, this will basically make servers signal to conforming clients "use SSL/TLS instead, connect to port XXXX". Clients would then automatically re-connect to the specified SSL/TLS port without user interaction. It is comparable to other protocols: it's similar to an HTTP to HTTPS redirect together with HSTS.
UnrealIRCd added support for draft/sts in August 2017. On the client side there is still very limited support for this draft, notable exception is IRCCloud which does support it.
Hopefully, more and more clients and servers will start supporting this. Once major clients such as mIRC support it and networks start deploying Strict Transport Security, the number of SSL/TLS users will rise quickly.
Step 5: Use trusted SSL certificates
Many IRC networks are ran by volunteers who are on a tight budget. This has resulted in the practice of using "self-signed" SSL certificates. These don't cost any money and are very easy to setup. The problem with this is that anyone can create such a certificate. Anyone can impersonate your server and in that way the server is vulnerable to a Man in the Middle attack.
In December 2015, Let's Encrypt started offering "real" trusted certificates for free. Since Let's Encrypt is a trusted Certificate Authority you fix the earlier mentioned Man in the Middle attack.
Nowadays, networks should really use a trusted certificate. Unfortunately, for multi-server networks with Round Robin DNS Let's Encrypt doesn't always integrate nicely, but for most IRC networks it's a good option. And if you don't like the effort required by Let's Encrypt then you can buy a paid certificate for only $10 per year.
With the earlier mentioned Strict Transport Security from Step 4 it has also become mandatory for servers to provide certificates of trusted Certificate Authorities like Let's Encrypt. In fact, Strict Transport Security will fail to work if you use self-signed certificates.
Step 6: Block plaintext connections
The final step would be to only allow SSL/TLS connections. Unfortunately, as of 2017 IRC isn't ready for this... yet.
In the meantime you could use channel and user modes to enforce SSL/TLS on an individual basis. You can set channel mode +z (UnrealIRCd and InspIRCd) or +S (freenode) to only allow SSL/TLS users to join your channel. Similarly, you can set user mode +Z (UnrealIRCd) to only allow SSL/TLS users to private message you.
NOTE: The actual user- and channel modes you need to use will differ between IRC server packages.
plaintext-policy
In UnrealIRCd we recently added something called plaintext-policy by which server administrators can define what happens to users/opers/servers that connect using plaintext (non-SSL/TLS). The default policy right now is: allow users, warn ircops and deny non-SSL/TLS servers. Later on we will change the default policy to deny ircops (/OPER without SSL/TLS).
The policy is advertised in "CAP LS" as unrealircd.org/plaintext-policy. Perhaps it will become an official draft or standard later on.
Criticism
Some people argue that adding SSL/TLS to IRC only adds marginal security, perhaps even a false sense of security. They generally raise the following points:
IRC does not provide end-to-end encryption
This is true (well, unless you use OTR). If you don't trust the server or network then you either shouldn't use it or keep in the back of your head that everything you write may be intercepted or logged by the server.
It's a valid point but it isn't any different from a website, forum or social media like Facebook.
The other party may not be using SSL/TLS
If the person you are chatting with does not use SSL/TLS then your traffic will still travel unencrypted from the IRC server to the other person. This, you can prevent, scroll up to Step 6 for more information.
IRC conversations are public anyway
Most channels can be joined by anyone. Once you are in the channel you can see all conversations. So if you want to see all communications in channel #cats you can just /JOIN #cats.
This too is true. However, you can clearly see in the nicklist who is in the channel. In fact, the public nature of chats is also something that makes IRC kind of special. It is different from for example WhatsApp groups where you will only invite friends. On IRC anyone with a similar interest can see and join your channel, unless you configure it otherwise.
IRC provides plenty of options to impose restrictions, such as: hiding your channel from the channel list (+s, secret), adding a channel password (+k, key) and/or making the channel "invite only" (+i).
Why SSL/TLS is useful
While SSL/TLS doesn't ensure complete confidentially of all your chats, there are still plenty of situations where using SSL/TLS is useful. It prevents interception between you and the IRC server and even critics will have to admit that even just that is useful in a number of scenario's:
- When using public access points
- Protection against TCP/IP session hijacking
- In nations with no or reduced freedom of speech
- If you don't like mass surveillance
- Add your own reason here...
Personally, I'm all in favor of seeing more usage of SSL/TLS. I hope that one day we can reach the earlier mentioned Step 6 on all networks out there.