Written: 31-03-2018 (Jaruga)

Internet Relay Chat

Internet Relay Chat (or 'IRC' for short) is an application layer protocol that facilitates communication in the form of text. The chat process works on a client/server networking model. An IRC client is software that allows for client-side use of the IRC protocol and the ability to connect to a server or network. IRC is mainly designed for group communication in real-time discussion feeds called 'channels', but IRC also allows one-on-one communication via private messages as well as data transfer, including file sharing.

The IRC protocol supports a number of features that can be utilized to increase the security of the connection both with the server and other clients. Below is an overall outline of some of the most common and essential of those features, as well as advisories on how to perform them safely.

Complete IRC guides

SSL / TLS / General encryption

If the destination IRC server provides an onion service it should be used for additional protection. Depending on the threat model, it might be recommended to also compliment the connection with TLS, SSL or another form of encryption like GPG.

Having another extra layer of encryption makes it harder for a potential adversary to compromise the confidentiality of the information in transit. Further, adding an additional layer of encryption via SSL or TLS does not have a negative impact on performance, and thus the many positives outweigh the virtually non-existent negatives.

If the IRC server is using a self-signed certificate (this is almost always the case with onion services using TLS), users must ensure the correct SSL or TLS certificate is used. This ensures an adversary cannot perform a Man-in-the-Middle attack between the IRC client and the server and thus tamper with the connection stream. The IRC client needs to be configured to only trust valid certificates, and the self-signed certificate needs to be imported.

Connection pathways

Below are basic outlines of how connections are chained in various scenarios.

Connecting to an onion-based IRC server:

Local system <--> IRC client <--> Tor's local socks proxy <--> Tor network <--> onion service <--> IRC network

Connecting to a clearnet-based IRC server:

Local system <--> IRC client <--> Tor's local socks proxy <--> Tor network <--> Tor exit node(s) <--> public/open internet <--> IRC server


If preferred, it is possible to set up firewall rules for the IRC client that ensure packets are only routed via Tor and that DNS queries are handled safely. Alternatively, it is possible to simply block all outbound non-Tor packets all together. Instructions performing this on most UNIX systems with iptables can be found here. If another type of firewall is in use, the commands on that page can be easily converted.

Circumventing Tor bans

PLEASE do not abuse the Tor network! Many IRC servers outright block all Tor connections due to ban evasion and repeated offenses. The Tor Project does not condone this behaviour, nor is it very kind - please be considerate of your fellow Tor users!

Some larger IRC networks require users to register when they connect for the first time. Unfortunately, many also block Tor connections due to spam and bots, and this can cause legitimate Tor users to have their connections constantly denied. However, if a user were to connect without Tor first to perform registration, then their anonymity would already be compromised. This is not dissimilar to the classic 'chicken and egg' problem. In most cases this is only an issue for initial registration, and SASL can be utilised to authenticate before any other part of the connection afterwards. Regardless, users should never connect without Tor or choose the "Bypass network proxy" option or similar on any clients.

Solution 1: Exit-node cycling

If a Tor exit-node is blocked or denied by an IRC server, the easiest solution is to cycle exit-nodes until you are connected to one that is not blacklisted. This may take some time to perform, but is the most secure option.

Solution 2: Psuedo-anonymous chaining

Warning: This should only be done for registration. Chaining proxies and VPNs after Tor long-term can reduce your anonymity in a number of ways.

The (albeit significantly less safe) alternative is using a free VPN, reflector, proxy or other pseudo-anonymous connection method to register an account. Ensure that the system only attempts to connect to any of these options via Tor, and always prefer to use SSL to connect to the destination IRC server. Unfortunately, very few other viable alternatives are available.

Miscellaneous security measures

Ident faking

In both UNIX and Windows systems, the logged in username becomes the default ident. The ident is seen by most clients during channel join and when performing the /​whois command. It is therefore recommended to fake your ident before you connect to any IRC servers.

Preventing leaks

This is heavily dependent on the IRC client of choice, however there are instructions within the wiki pertaining to safely torifying various IRC clients listed near the top of the page.


SASL is a type of user login and authentication method that allows identification to services such as NickServ during the connection process, before anything else occurs.

If a server requires users to use SASL then it is advised to use 'PLAIN' mode SASL authentication only if you are connecting on a SSL secured port of the destination IRC server, and all connections between you and destination server are using SSL encryption as well.

Cloaks and vhosts

By default, the local machines hostname is viewable to others in IRC as well as through the /whois command. Some IRC networks allow users to cloak their host, most often with a special command like '/mode <yournick> +x'. Consult the IRC network operators to find out if that is supported. Please note that the IRC server admins can still see what's behind the cloaked hostname/IP.

Additionally, some servers offer a vhost (short for 'virtual host') system. This method is often done while logged in, sometimes requiring a visit to a channel or issuing a bot command. Again, it is advised to inquire with the server operators as to their course of action.

Avoid double connections

NEVER connect to the same server via an anonymous connection or identity and a non-anonymous connection or identity simultaneously! This is a massive danger to OPSEC!

Hardening IRC clients

To additionally increase security, anonymity and privacy, it may be worth hardening your client (if possible). In an effort to reduce your attack surface it is also advisable to deactivate all unused features and protocols.

Client-to-Client Protocol and Direct Client-to-Client

Deactivate both /CTCP and /DCC commands - they leak information about the local system. ​DCC is a protocol primarily used for the purpose of file transfer. It is advised to disable it as DCC attempts to make a connection outside of Tors encrypted stream, and can therefore expose the local machines true external IP.

IRC client local logging

By default, most IRC-clients create local logs, of everything the client does. Depending on user preferences, this may be disabled.

End-to-end encryption and authentication

Most IRC clients support Off-the-Record Messaging. Please refer to your clients documentation or the Tor wiki guides to learn how this is performed.

The other option is using a GnuPG plugin. Once more, this information can be found in the IRC clients relevant documentation.

Quit, leave and away messages

Some IRC clients have identifying status messages. It is advised turn those features off if possible.

Social safety measures

Trusting users and servers

Users should never trust any person they solely know as a screen name - as much as one thinks they know someone else, it is impossible to be entirely sure until they are standing directly in front of them. It's important to maintain strong operational security at all times when attempting to remain anonymous, especially in live chat scenarios. Also be advised that IRC server administrators have the power to impersonate users. It is therefore recommended to be cautious when connecting to unknown networks.

It's also highly recommended to avoid following any links or accepting any files via IRC from unknown or little-known sources. Use best judgement.

Personally identifiable threads

From the ​JonDonym documentation (​Permission was granted for reproduction here):

IRC chats are public, keep that in mind. Deanonymsation is not only possible with IP addresses, but by social threads too. Some recommendations to avoid deanonymisation collected by Anonymous:

  • Do not include personal information in your nick and screen name.
  • Do not discuss personal information in the chat, where you are from...
  • Do not mention your gender, tattoos, piercings or physical capacities.
  • Do not mention your profession, hobbies or involvement in activist groups.
  • Do not use special characters on keyboard, which are existent only in your language.
  • Do not post information to the regular internet while you are anonymous in IRC. Do not use Twitter and Facebook. This is easy to correlate.
  • Do not post links to facebook images. The image name contains a personal ID.
  • Do not connenct to chat at the same time. Try to alternate.

Heroes only exist in comic books keep that in mind! There are only young heroes and dead heroes.

Change NickServ passwords regularly

It's advised to change passwords for IRC networks regularly. If a system is believed to be compromised, the user should immediately contain the threat and immediately update their passwords following an all-clear.

Extra steps

Checking your fingerprint before using IRC

To check your fingerprint from a third person perspective, simply log onto a server using a different, unidentifiable nick. For example, "guest3028t". Before joining any channels, ensure sure you look like intended, check that by performing /whois on your temporary nickname, i.e. '/whois guest3028t'. In case something is wrong, disconnect. Otherwise if everything looks fine, change your nickname to your desired nickname and join channels.

See also

Last modified 2 years ago Last modified on May 23, 2018, 8:48:39 AM