Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

Post reply on HN
Print view View original

331–340 of 414 posts

Re: The Day the Telnet Died

#331

Post by RupertSalt »

zenethian wrote: post #327
RupertSalt wrote: post #326

Earlier quoted context omitted.

[flagged]

Can you show the exact line in the RFC or IANA port reservations that says it has to implement a shell login interface with the Telnet protocol if it’s on port 23? Because I can’t find it. Nothing says that anywhere.

I literally already did. And it is not merely the RFC which specifies it. The RFC defines the protocol and really leaves it open-ended for any sort of implementation.

What defines port 23/tcp is the longstanding usage and the original understanding of a "remote terminal" or NVT. In 1983 when the IETF described the NVT, it was simply understood that a terminal, or "canonical console", was a method to access a timesharing system and log in as a user. If you went to a "terminal lab" or you sat down at a desk with a "terminal" or "teletype" or any of its predecessors, you were preparing to log in and do some programming or data processing.

There were literally no terminal labs where you would sit down and begin playing Centipede, Asteroids, or PONG. Those were completely different concepts of "consoles" and "cabinets" and the IETF did not stutter when they defined an NVT.

Every Unix implementation, every router and network device, practically anything with an Internet connection implemented a "shell" login on port 23 or it did not. There were plenty of systems with /usr/games and a plethora of leisure-time activities, but surprisingly they did not default to using port 23/tcp. It has been long-standing tradition, and convention, that the TELNETD service operating on 23/tcp is what a user expects to find when they connect.

MUD admins and wizards who put their servers on 23/tcp necessarily needed another way to log in and manage their server. I am surprised that they were so easily able to usurp telnetd if this was the status quo. Was sshd already established for them or something? Did they just resort to rlogin instead? I'm genuinely clueless and curious how it was so easy to usurp 23/tcp and use it for MUDs.

Because my community often ran them clandestinely, and we always ran them unprivileged, so there would literally be no way for the server to start on port <1024 -- it never ever had root access! If your MUD ran on port 23, that's dangerous because at some point, somewhere, some time, it enjoyed root access, and hopefully dropped that UID 0 immediately after the bind()!

Re: The Day the Telnet Died

#332

Post by nephihaha »

prerok wrote: post #276
nephihaha wrote: post #242

Earlier quoted context omitted.

Even that's argued within linguistics. There are languages which survive for generations as secondary languages (especially trade languages as Swahili or Chinook Jargon appear to have been originally). Also some like Latin, Hebrew and Sanskrit which survive for centuries but not as native languages.

Can you cite sources where this is argued? The wikipedia seems to make a clear definition: https://en.wikipedia.org/wiki/Language_death That said, the above article does use extinction and death somewhat interchangably later on, but I suppose it's almost the same for small languages that nobody learns who is not a native speaker.

There are plenty of languages which exist without much in the way of L1 speakers. Esperanto, for example, although it does have a handful of native speakers. Many people speak English as a non-native language, particularly in places like India or Nigeria. Swahili was originally a trade language few folk spoke and even today, many of its speakers are L2.

I can speak and read some Manx. I personally don't believe it died in the 1970s. Not only do we have continuity from that time, there are people around today who learnt theirs off native speakers (in one case they were his close relatives.) It helps that we have many recordings, writings etc and it is also closely related to two languages which are in slightly better shape.

Latin and Hebrew were in use within the Middle Ages to a substantial level and used to communicate between people as a common language sometimes. Hebrew is now revived, but is Latin? A few people have spoken it as their first language over the last century or two.

Re: The Day the Telnet Died

#333

Post by PhilipRoman »

ajross wrote: post #311
PhilipRoman wrote: post #240

Earlier quoted context omitted.

>>Nobody verifies host keys, >The known_hosts file is verification of host keys I think the point was that those devices typically generate host keys dynamically and therefore the host key verification is usually turned off, leaving you just with encryption (which is still better than telnet - at least you're safe against passive adversaries). At least that's what I've seen in practice.

Host key verification is a client feature and is on by default. Have you really never gotten the giant warning after a reinstall? That's what that is. SSH is telling you that the server has changed and isn't what you think.

I'm saying that 90% of these setups look like this (or do the equivalent thing manually):

   ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168...
They have ssh, but no proper key management

Re: The Day the Telnet Died

#334

Post by 0xbadcafebee »

watermelon0 wrote: post #203
0xbadcafebee wrote: post #88

Earlier quoted context omitted.

Telnet is used in legacy, IoT, embedded, and low-level industrial hardware. It's also intentionally enabled on devices where automation was written for telnet and it wasn't easy to switch to ssh. If you investigate most commercial uses of ssh, the security is disabled or ignored. Nobody verifies host keys, and with automation where hosts cycle, you basically have to disable verification as there's no easy way around…

Unless you manage to leak your private host/client SSH keys, this is close to being as secure as it gets. I'd say that HTTPS (or TLS in general) is more problematic, since you need to trust numerous root CAs in machine/browser store. Sure, you can use certificate pinning, but that has the same issues as SSH host key verification.

CA compromise is very rare and difficult. There are much easier attacks on TLS than that (notably, attacking insecure validation methods; the problem isn't that CAs aren't secure, it's that validation methods and their dependencies are insecure). Besides, the CAs for TLS only covers transport security; authentication+authorization would be handled securely through OIDC, using temporary sessions and not exposing the true credential, often combined with 2FA. Even you successfully attack a TLS server, two factors, and an active session, it only works once; you have to keep pulling it off to remain inside.

Compare that to malware that just copies a developer's ssh private key off the disk (again, almost nobody ever password protects theirs). This just happened recently on a massive scale with the npm attacks. Or intercepts the first connection from a client host and, again, because nobody ever validates keys, injects a false host key, and now they're pwnd indefinitely. Or, again, companies that do not strictly validate host keys, meaning immediate MitM. There's like a dozen ways to compromise SSH. It doesn't have to be that way, but it is that way, because of how people use it.

Re: The Day the Telnet Died

#335

Post by varenc »

Suzuran wrote: post #321
NitpickLawyer wrote: post #216

Earlier quoted context omitted.

> Tier 1 transit providers doing port filtering is EXTREMELY alarming. I was admining a small ISP when blaster and its variants hit. Port filtering 139 and the rest was the easiest way to deal with it, and almost over night most of the ISPs blocked it, and we were better for it. There was a time when if you'd put a fresh XP install on the Internet you'd get 5-10 minutes until it would get restarted. I guess if you're…

I run a PDP-10 during the colder parts of the year. It's for historical preservation reasons. There are others doing the same thing. We still offer telnet access because that's how it worked back then. I guess we aren't going to be doing that anymore.

If you can get it on IPv6, maybe via a gateway, port 23 filtering doesn't seem to be applied to IPv6 yet! (I assume because the v6 address space is too large to mass scan?)

Re: The Day the Telnet Died

#336

Post by 0xbadcafebee »

PhilipRoman wrote: post #333
ajross wrote: post #311

Earlier quoted context omitted.

Host key verification is a client feature and is on by default. Have you really never gotten the giant warning after a reinstall? That's what that is. SSH is telling you that the server has changed and isn't what you think.

I'm saying that 90% of these setups look like this (or do the equivalent thing manually): ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168... They have ssh, but no proper key management

Exactly. But 'passive encryption' isn't helpful; if you can see the traffic, you can MITM it. Just RST the connection, wait for the reconnect, intercept.

Re: The Day the Telnet Died

#337

Post by roryirvine »

qingcharles wrote: post #262
Quarrel wrote: post #107

What an amazing bug. I probably spent my first 10 years on the internet just using telnet. They were wild times. You could log ethernet traffic and see passwords. Towards the end of those we started to have a few more single-user machines, but the vast majority were old school many many user machines, where "root" was thought to be tightly restricted (of course, even then, in practice it wasn't if you were in the kno…

When did we all stop using telnet? I can't even remember. Most of my first 10-15 years was using telnet. One day I used telnet to connect to a shell for the last time and didn't know it. I had a ton of servers all with root telnet access Internet facing. Never hacked once, somehow. Those were the days.

In the Linux / BSD world, SSH took off incredibly fast for the time. I'd estimate that maybe 80% of people had moved to it within the first year of its release.

But adoption stalled when the original SSH moved to a commercial license in 1996-ish - many of us stuck with the last free version, but vulnerabilities started to pile up. There were various half-working alternatives, but it wasn't until OpenSSH came out in 1999 that the remaining telnet holdouts started to move across.

Re: The Day the Telnet Died

#338

Post by sophacles »

RupertSalt wrote: post #275
VadimPR wrote: post #271

Earlier quoted context omitted.

Lots of text games - MUDs - still play over telnet using dedicated MUD clients that implement their own telnet stack. Outright blocking the port has an outsized side efffe on them, this is simply not right.

If MUDs and other games were indeed using port 23/tcp for player access, they were not only incorrect but rather dangerous. Since 23/tcp is a well-known IANA-registered port for the Telnet service, it is an RFC violation to use it for a service that is not telnetd/remote logins via TELNET protocol. Any port below 1024 signifies that it is a "privileged port". This is an archaic distinction that developed in high-trus…

> it is an RFC violation

I hate to break it to you, but RFC violations power the internet.

Also, RFCs are non-binding and the IANA port numbers are just strongly suggested.

Re: The Day the Telnet Died

#339

Post by ajross »

PhilipRoman wrote: post #333
ajross wrote: post #311

Earlier quoted context omitted.

Host key verification is a client feature and is on by default. Have you really never gotten the giant warning after a reinstall? That's what that is. SSH is telling you that the server has changed and isn't what you think.

I'm saying that 90% of these setups look like this (or do the equivalent thing manually): ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168... They have ssh, but no proper key management

Well, sure. You can turn off host key checking in ssh! But that isn't responsive to a point that (1) host key validation exists in ssh and (2) host key validation is on by default in ssh.

Re: The Day the Telnet Died

#340

Post by sophacles »

ncruces wrote: post #254
tosti wrote: post #236

Earlier quoted context omitted.

It's not a net-neutrality issue because they're not banking on any alternative. Net-neutrality law doesn't work like that. Service providers still get to filter stuff. What's illegal for an ISP is e.g. to give VoIP services other than their own a lower priority. That would tie in customers to use their own service and they could even charge more for it. Net neutrality means a level playing field for services on the I…

This is not an ISP. It's a Tier 1 transit provider.

My ISP (AT&T) is a tier 1 transit provider.
Post reply on HN