I have a 35k$ worth Xray flat panel detector (still have >5k$ ebay value today), it runs embedded linux on an obsolete samsung ARM processor and uses telnet to talk to the console computer through a point to point ethernet link.
Apparently, it's impossible to migrate to ssh and why the ** I need to care about security here?
No. You understood the phrase incorrectly and assume I mean "bang the head against the wall and don't you telnet". Of course if you have no other choice, go for it. But if you do...
Ok. Telnet is a protocol, it is not synonymous with TCP.
As for unencrypted traffic generally, I see no reason for fetishizing encryption. "Compute" is not synonymous with teh cloudz. Cloud tech is not synonymous with teh cloudz. It's trivial to put e.g. Nginx in front of something.
If you need encryption between 127.0.0.1 and 127.0.0.42 you clearly don't trust the hardware you're running on; I'm sure someone's got some clever way of hiding the private keys, but "clever" doesn't mean provably secure. Between containers... meh. Show me you thought about it and have a threat model.
Between datacenters... not so much. Do I care whether the connection is encrypted, or whether all traffic goes through a tunnel? I'd like to see a threat model. Is sigint included?
Even across the globe I might make an exception for a well-reasoned argument. That would almost certainly have to be data which was an observable: the time, a flow rate. Encryption is not the same as tamper-proof. Even unencrypted data might need defense against that. (Maybe secrecy is easier than nonrepudiability. Maybe.)
Secrecy is not identical to privacy. Security is not identical to either of those, and hypervigilance isn't the same as not needing to be concerned with something (these days security can be either of those). Observability might be more important than either secrecy or privacy depending on the application, and who is doing the observing.
A lot of it depends on where you demarc your rings of hell and how you defend things.
I send data in the clear sometimes and I'm ok with it. I also use a telnet client for decidedly "not telnet protocol" purposes related to diagnostics as well as observability.
I dont see why a thread model is needed here, encryption is always important, especially in big corps. It seems like you're stating that a normal person doesnt need security.
Not sure why everyone thinks that telnet is "not suitable for today especially in the case of security", although telnet over TLS exists. There are also certain things that telnet can do which SSH cannot (e.g. transport data for a block terminal).
And everyone who uses "telnet as a program for connecting to a server on any port and talking the protocol manually" forgot that telnet is a real protocol and this type of abuse only works if the telnet client is sufficiently dumb / doesn't negotiate parameters. There is a reason why netcat exists.
Those are data formats, and a client is needed to support those (on both endpoints). You better just use something modern like ssh instead of hunting for clients (and making sure they're reliable).
Telnet as a way of logging in to a remote system is bad, sure, but telnet as a program for connecting to a server on any port and talking the protocol manually was great, especially before http got so complicated.
Yes, but that doesn’t mean you just leave telnet running decades after it became obsolete. That should be a time limited waiver and mitigations, and if you have legacy devices which absolutely need Telnet you should be planning for what you’ll do when something that old finally breaks and you have the resources to port relatively simple code.
This is circular: sure, if telnet is _obsolete_, then remove it. But being obsolete exactly means no one is using it anymore. If someone is using it, then it's not obsolete.
Regarding security, some would advocate that telnet, or whatever else, is secure at least as much as the network underlying it. So anyone who puts their "legacy" telnet apps on a VPC is fine, and has decades more to enjoy software that has already been running for decades.
Telnet has been obsolete since the turn of the century. That doesn’t mean that nobody uses it but it does mean that everyone who does should be upgrading away from it.
Trusting the network for security was common in the previous century but standards have improved since then. For example, sending your password in clear text is no longer considered acceptable by mainstream security standards since it avoids the risk of passive network monitoring or accidental exposure.
Obsolete means no longer in use or useful. It's been argued in this thread that it's both in use and useful. But yes, there are more secure protocols that overlap with most of what telnet can be used for.
Obsolete doesn’t mean something has no possibility of being useful but rather that it’s no longer commonly used because there are better alternatives. My son’s beloved steam locomotives still run but nobody uses them for normal commercial service because they became obsolete shortly after the invention of diesel and electric.
> (of words, equipment, etc.) No longer in use; gone into disuse; disused or neglected (often in favour of something newer)
Bringing that full circle, telnet used to be common but it has security issues (lack of encryption or integrity unless you tunnel over TLS, lack of modern authentication options, etc.) and so anywhere it’s still used we should be looking in to replacing it.
As discussed in the thread above, there are scenarios in which lack of encryption etc is simply not relevant. And when that is the case, why would you prefer a more complicated protocol with more moving things that can go wrong?
Telnet is still in use for its primary purpose, which is a bit different than a locomotive which has been neglected to a tourist attraction. Your last paragraph means you would like to make telnet obsolete, but it isn't yet. As evidenced in the thread, it's not partical or desirable to replace it with other technology in all the deployments of it. So, it's still hanging in there for now.
One does not use telnet as telnet when doing security work. Telnet + sclient (you can also use tons of other tools, too) lets you inspect many servers that have TLS security. SSH does not.
