Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

221–230 of 414 posts

Re: The Day the Telnet Died

#221
post #215

Earlier quoted context omitted.

Stop spamming AI slop

?

because it reads like claude output?

and also the pattern:

> The most interesting thing here isn't the CVE… This is what mature security…

> The most interesting finding isn't that hyperbolic growth… This is Kuhnian paradigm…

both comments in the last 24h

Re: The Day the Telnet Died

#222

On the bright side that CVE seems like pretty great news for the hardware hacking community hoping to get root on embedded devices which have open telnetd.

I just tried on a Zyxel Wifi AP I have.

It seems to use a different telnetd (busybox?), because from what I can tell it's not prone to this error.

Re: The Day the Telnet Died

#223
post #217
post #213

Earlier quoted context omitted.

I do not know what is more critical: the risk of censorship or stand by while hospitals, banking, nuclear power plants and other systems become compromised and go down with people dying because of it. These decision makers not only have powers but also have a responsibility

This feels more akin to discovering an alarming weakness in the concrete used to build those hospitals, banks and nuclear power plants – and society responding by grounding all flights to make sure people can't get to, and thus overstress, the floors of those hospitals, banks and nuclear power plants.

You feel it's similar because having access to port 23 is similarly life critical as having access to an hospital? Or is it because like with ports, when people can't flight to an hospital, they have 65000 other alternative options?

Re: The Day the Telnet Died

#224

Earlier quoted context omitted.

netcat, socat and openssl s_client are all available for general manual connection testing. As are many other tools. But the ones above are basically far better direct telnet alternatives.

I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?

Same reason that people use vi. It's always there.

Re: The Day the Telnet Died

#225

Earlier quoted context omitted.

I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?

Because for a long time, on most computers, the telnet client was the closest thing to an "open a tcp socket to this ip/port and connect the i/o from it to stdin/stdout" application you can get without installing something or coding it up yourself. These days we have netcat/socat and others, but they're not reliably installed, while telnet used to be generally available because telnetting to another machine was more…

You don't even need netcat or socat for that, probing /dev/tcp// from the shell is enough.

Re: The Day the Telnet Died

#226

Why are people still using telnet across the internet in this century? Was this _all_ attack traffic? (OK, I know one ancient talker that uses it - but on a very non-standard port so a port 23 block wouldn't be relevant)

How else would I connect to my BBS to play L.O.R.D. and check FidoNet.

Re: The Day the Telnet Died

#227

Earlier quoted context omitted.

I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?

Because it's there.

It hasn't for the most part of the last 2 decades.

Re: The Day the Telnet Died

#228
post #223
post #217

Earlier quoted context omitted.

This feels more akin to discovering an alarming weakness in the concrete used to build those hospitals, banks and nuclear power plants – and society responding by grounding all flights to make sure people can't get to, and thus overstress, the floors of those hospitals, banks and nuclear power plants.

You feel it's similar because having access to port 23 is similarly life critical as having access to an hospital? Or is it because like with ports, when people can't flight to an hospital, they have 65000 other alternative options?

All I'm saying is that the only right place to fix this is at the hospital. Not at the roads leading to it.

Re: The Day the Telnet Died

#230
post #213

Never mind telnetd. Tier 1 transit providers doing port filtering is EXTREMELY alarming. They have partitioned the Internet, and in a way that automatic routing (BGP) can't get around.

I do not know what is more critical: the risk of censorship or stand by while hospitals, banking, nuclear power plants and other systems become compromised and go down with people dying because of it. These decision makers not only have powers but also have a responsibility

Have you ever seen a hospital, a bank, a power plan to expose telnetd to the public internet in the last 20 years? It should be extremely rare and should be addressed by company’s IT not by ISPs.
Post reply on HN