Back in the early 2000s, running IRC over TLS was an exotic configuration that maybe 5% of users bothered with. Plaintext on port 6667 was the default, and nobody thought twice about their messages — including NickServ passwords — traveling across the internet in cleartext. Times change. In 2026, if you're connecting to IRC without TLS, you're doing it wrong.
Why TLS Matters on IRC
The threat model for unencrypted IRC is straightforward:
- Passive eavesdropping: Anyone on the network path between you and the IRC server can read your messages. This includes your ISP, your employer (if you're on a corporate network), anyone on your WiFi network, and any intermediary network operator.
- Password interception: NickServ passwords sent over plaintext connections are trivially interceptable. If someone captures your NickServ password, they can impersonate you on the network.
- Session hijacking: Without encryption, an attacker could potentially inject messages into your IRC session, making it appear that you said things you didn't.
- Metadata collection: Even if message content isn't sensitive, the metadata — who you talk to, which channels you're in, when you're active — can be revealing.
TLS encrypts the connection between your client and the IRC server, preventing all of the above. It doesn't provide end-to-end encryption (the server still sees everything), but it eliminates the most common attack vectors.
How TLS Works on IRC
IRC over TLS works exactly like HTTPS — the same TLS protocol, the same certificate infrastructure, the same encryption algorithms. The only difference is the application protocol running on top.
By convention, IRC servers offer TLS on port 6697 (compared to plaintext on port 6667). Some servers also support STARTTLS, which upgrades a plaintext connection to TLS mid-stream, but this is less common and less secure than a direct TLS connection (since the initial handshake is unencrypted).
When your client connects to port 6697, the TLS handshake happens before any IRC protocol data is exchanged. The server presents its certificate, your client verifies it (against your system's CA store or a pinned certificate), and once the encrypted tunnel is established, normal IRC communication proceeds inside it.
Client TLS Setup
WeeChat:
/server add libera irc.libera.chat/6697 -tls
/set irc.server.libera.tls on
/set irc.server.libera.tls_verify on
/connect liberairssi:
/server add -tls -tls_verify irc.libera.chat 6697 liberachat
# Or in config:
{
address = "irc.libera.chat";
chatnet = "liberachat";
port = "6697";
use_tls = "yes";
tls_verify = "yes";
}HexChat: In the network list, check "Use SSL for all the servers on this network" and ensure the port is 6697. Also check "Accept invalid SSL certificates" ONLY if you know what you're doing (e.g., connecting to a server with a self-signed cert).
Critical: Always enable certificate verification (tls_verify). Without it, your client will accept any certificate, including one from an attacker performing a man-in-the-middle attack. Certificate verification ensures you're actually talking to the server you think you're talking to.
SASL Authentication
SASL (Simple Authentication and Security Layer) is the preferred method for authenticating to IRC services over TLS. Instead of sending your NickServ password after connecting (which has timing issues and can fail if services are lagging), SASL authenticates you during the connection process itself.
SASL PLAIN (username/password over TLS) is the most common mechanism:
WeeChat:
/set irc.server.libera.sasl_mechanism plain
/set irc.server.libera.sasl_username YourNick
/set irc.server.libera.sasl_password YourPassword
/saveirssi with cap_sasl script:
/load cap_sasl
/cap_sasl save liberachat YourNick YourPassword PLAINSASL EXTERNAL (authentication via client TLS certificate) is even better — see CertFP below.
CertFP: Certificate Fingerprint Authentication
CertFP is the gold standard for IRC authentication. Instead of a password, you authenticate using a TLS client certificate. The server (or services) recognizes you by the fingerprint of your certificate. No password to intercept, no password to remember, no password to type.
Setting it up:
# Generate a self-signed certificate:
openssl req -x509 -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
-days 3650 -nodes -out irc.pem -keyout irc.pem \
-subj "/CN=marco"
# Get the fingerprint:
openssl x509 -in irc.pem -outform der | sha512sum -b | cut -d' ' -f1Configure your client to use the certificate:
WeeChat:
/set irc.server.libera.tls_cert "%h/irc.pem"
/set irc.server.libera.sasl_mechanism externalirssi:
# In irssi config:
{
address = "irc.libera.chat";
port = "6697";
use_tls = "yes";
tls_cert = "~/.irssi/irc.pem";
tls_verify = "yes";
}Register the fingerprint with NickServ:
/msg NickServ CERT ADDFrom now on, when you connect with that certificate, NickServ automatically identifies you — no password needed. If you lose the certificate, you can still authenticate with your password as a fallback.
Server-Side TLS Configuration
If you're running your own IRC server, TLS configuration is straightforward but has a few gotchas:
- Use Let's Encrypt: Free, automated, widely trusted. No reason not to use it.
- Disable old protocols: TLS 1.0 and 1.1 should be disabled. Only allow TLS 1.2 and 1.3.
- Use strong cipher suites: Prefer ECDHE key exchange and AES-GCM or ChaCha20-Poly1305 ciphers.
- Auto-renew certificates: Let's Encrypt certificates expire every 90 days. Set up automatic renewal and server rehash.
- Server-to-server TLS: Links between servers should also be encrypted. This is separate from client-to-server TLS and needs its own certificate configuration.
Common Pitfalls
Wrong port: The most common TLS issue. Port 6667 is plaintext. Port 6697 is TLS. Connecting with TLS to a plaintext port (or vice versa) produces mysterious connection failures.
Certificate verification failures: If your client rejects the server's certificate, it's usually because the system's CA store is outdated. Update your CA certificates: sudo apt install ca-certificates && sudo update-ca-certificates.
Self-signed certificates: If you're connecting to a private server with a self-signed cert, you'll need to either import the certificate into your client's trust store or disable verification for that specific server (not recommended for production).
SNI (Server Name Indication): Some IRC servers host multiple TLS domains on one IP. If your client doesn't send the correct SNI hostname, you might get the wrong certificate. Most modern clients handle this correctly, but older versions might not.
Bouncer chain: If you use ZNC or another bouncer, you need TLS on both connections — client to bouncer AND bouncer to IRC server. Encrypting only one leg leaves the other exposed.
Frequently Asked Questions
Does TLS make IRC completely secure?
TLS encrypts the connection between your client and the server, but the IRC server itself can see all messages in plaintext. For true end-to-end encryption between users, you'd need an additional layer like OTR (Off-the-Record messaging). TLS protects against network-level eavesdropping, not against a compromised server.
Do all IRC networks support TLS?
All major networks (Libera.Chat, OFTC, EFnet, IRCnet, Undernet) support TLS on port 6697. Some smaller or older networks may not. If a network doesn't offer TLS, consider whether you trust it enough to send data in plaintext.
What's better: SASL PLAIN or SASL EXTERNAL?
SASL EXTERNAL (CertFP) is more secure because no password is transmitted at all — authentication is based on your TLS certificate. SASL PLAIN sends your password encrypted inside the TLS tunnel, which is safe against network eavesdroppers but means the server receives your plaintext password. For maximum security, use EXTERNAL.
Can I use IRC over Tor with TLS?
Yes. Tor encrypts the connection to the Tor exit node, and TLS encrypts the connection from the exit node to the IRC server. This provides both anonymity (Tor) and encryption (TLS). Some IRC networks also offer Tor hidden services (.onion addresses), which provide end-to-end encryption within the Tor network.
FAQ
Should I use TLS on my IRC server?
Yes, always. TLS protects credentials and messages in transit. Most modern clients default to TLS, and many networks require it. Use port 6697 as the standard TLS port.
Can I use Let's Encrypt for IRC?
Yes. Let's Encrypt certificates work perfectly for IRC servers. You need to automate renewal (certbot renew) and configure your IRCd to reload certificates automatically or via a cron job.
What about self-signed certificates?
Self-signed certs provide encryption but no identity verification. Users will see certificate warnings. For public-facing networks, use a proper CA like Let's Encrypt. For private networks, self-signed with certificate pinning is acceptable.