12 ms·
I've used telnet as the client wait in the distant pass. Those were the days.
by sys_64738 6y ago
I've used telnet as the client wait in the distant pass. Those were the days.
- Fnoord 6y agoYou 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...
- sys_64738 6y agoI 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.
- Fnoord 6y agoI 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.
- Macha 6y agoThe 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
- a1369209993 6y ago> 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.
- Fnoord 6y ago> 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.
- hombre_fatal 6y agotelnet for MUDs too. Such a simple interface for such complex worlds is something that still fascinates me.