Hacker News Reader

Comment by userbinator | Hacker News Reader

The IRC protocol is both text-based and simple enough that you can use something like netcat as a client (and I have, many times.) The line-based format fits IM perfectly, and the overhead of the protocol is a tiny fraction of the bloated proprietary ones that have filled this use-case today (except MSNP, which in its earlier versions was also delightfully simple and easy to write a client for, but definitely beyond the threshold of being usable "raw".)

View on HN

The problem with that is that IRC networks generally send you a ping every 5 minutes or so, and if you don't send a PONG back in time you are disconnected.

It varies on network but the timing on that was pretty generous. Seen some networks where it gave you entire minutes to respond

I've used telnet as the client wait in the distant pass. Those were the days.

You could use netcat (or something akin to it). Back in the days I tunneled that via stunnel to get TLS [1] support. One could do the same with POP3 and IMAP.

One problem with this workflow is that in some clients (e.g. IRC client supporting TLS) the user had no way to identify/verify the certificate. If a client just automatically accept self-signed certificates, its just snake oil.

[1] Everyone still called it SSL back then. Oh, wait...

I never did SSL from telnet for sure, in fact I didn't know IRC supported encryption back then. There was also the ident response that was needed - can't recall the particulars as it's been 20+ years.

I was talking end of 90s. UnrealIRCd (mainly Carsten Munk / stskeeps) was one of the first to support TLS/SSL. At some point in start of 00s the popular IRC networks slowly but surely started to support it. There's also the case for cryptography between servers, something UnrealIRCd also was quick to adapt.

Some servers required ident(d) response which required a server running on privileged port 113.

The one issue for the longest time was that networks would use self signed certs and often different certs per server in the network, so it was hard to have any kind of trust. I did see a few using Let's Encrypt in recent years but moved over to Matrix these days

> If a client just automatically accept self-signed certificates, its just snake oil.

It forces attackers to use a active attack rather than a passive one. Which is the only security most IRC can have anyway, since the attacker could just join the channel and listen in that way, since most IRC networks are public.

> It forces attackers to use a active attack rather than a passive one.

The MITM or eavesdrop can happen on a bridge. If the client doesn't check the certificate and accepts any, its about as good as plaintext. It could be worse, even, due to the false sense of security.

> Which is the only security most IRC can have anyway, since the attacker could just join the channel and listen in that way, since most IRC networks are public.

IRC network private or public is irrelevant.

There were, for sure, private channels back in the days (90s). Back then you could set a channel secret (hidden) and set a password on it, effectively making it a private channel (would not show up in /whois or /list). Bots could kick people who are unknown based on filters. For example, without an auth to an Eggdrop, you could get insta kickbanned even _with_ the correct password.

Then there's PMs which are one on one (except for server(s)).

If one of the IRC servers is compromised though (or tapped, or whatever), that makes sniffing a channel or PMs child play.

There's also the problem of data integrity. If you are asking for (or giving) help in #linux and someone can change the data on the fly, [...]

FWIW, UnrealIRCd, even back then, innovated (or invented) a lot of new features on top of IRC. Some of these added security, though I don't know examples out of my head.

telnet for MUDs too. Such a simple interface for such complex worlds is something that still fascinates me.

Like books

And Nethack/Slashem servers :D.

So you can play RPGs remotely from any crap built from the 80's with serial support and a 80x24 display (WIFI232), on the display, a Spectrum +3 would suffice.

IRC has the issue that it lacks end to end encryption (and sadly OTR is outdated garbage)

If you use netcat you also do not use tls, try openssl s_client -connect server:port instead.

I generally support end-to-end encryption for everything, but I'm not sure that it makes sense in the context of IRC. IRC networks are usually public, so anyone could join your channel and listen in, even with end-to-end encryption. It seems like E2E would make for a lot of complexity and overhead without tangibly increasing the privacy of the users.

There are private IRC channels (password protected or invite-only) as well as private messages.

Hence the "usually" public, I presume. While this doesn't invalidate your point that IRC could use E2E encryption, I personally only use IRC for communication on public channels, where it would be largely pointless, unless you're assuming a really paranoid threat model, in which case public group conversation is probably not a good idea anyway.

exactly this

if it's public: who cares, and if it isn't: why are people trusting random IRC server admins

especially when there have previously been leaks from places like EFNet where admins have been caught running tcpdump or ircsniff.pl

> why are people trusting random IRC server admins

e2ee means that you do not have to trust anyone

> if it's public: who cares

IRC also lacks end to end authentication, the server owner can pretend to be you.

There's dcc chat, but then you trust the network in general in place of the irc network.

Fortunately, there's OTR, but client support is limited.

I wish the new ircstandarization efforts did work something out about e2e, at least for private messages.

Before E2EE was used in IM clients, IRC already had IRC over TLS, and also OTR (which was also used in Gaim/Pidgin).

On IRC, IRC over TLS doesn't have the same threat model as E2EE. With IRC over TLS, the server(s) can read the data plaintext. With proper E2EE (not the marketing version) that's not the case; only clients can read the data. I'm talking about actual data/content here; not metadata.

> IRC networks are usually public, so anyone could join your channel and listen in, even with end-to-end encryption.

Yep, and all they'd see is encrypted garbage, unless they have encryption keys, if the messages are end-to-end encrypted. That's the whole point.

There are ways to do this on IRC (e.g. libfish), but no idea how that crypto actually stacks up by todays standards.

> and all they'd see is encrypted garbage, unless they have encryption keys, if the messages are end-to-end encrypted.

Yep, and they would have the encryption keys, for most channels, if the channels are to remain public, no?

Reply on news.ycombinator.com