Reports of Telnet's death have been greatly exaggerated
terracenetworks.com
terracenetworks.com
Back then we had large monitors with black background and green text font; for most people black background and white text was probably more common, but I remember having played that MUD for some weeks on such a setup (on a campus site, so these computers were used by students; we only had access to the campus on the weekend as the main guy's father in our group worked at that university).
It actually was fun to use telnet like that and play the MUD, even if inconvenient. Of course our group soon switched to MUD clients that were more convenient to use, so using telnet became super-rare. I only used telnet a few more times after that. About three times again playing lateron when I had no internet connection, and for a few other things too, unrelated to MUDs, e. g. testing websites and similar activities.
For connections, I kind of use ssh much more frequently so, even on windows via the tabby terminal. It is not as convenient on Linux (there I tend to prefer KDE konsole) but it works fairly well.
I have not used telnet in quite some years now, but I still remember fondly to having typed commands to search for herbs in a meadow on that MUD (well, room designated was meadows and you could find herbs which would replenish over time, so you could search, sell and so forth; I have not played any MUDs since decades but it was fun in the 1990s era).
Telnet will probably never die since it is so simple, but I think it is also not quite as important as it was, say, in the 1990s or so. Would be interesting for statistics that could measure this more objectively.
For Tiny* servers, "raw telnet" was considered a ghetto experience. The worst part was that the asynchronous output would just stream in whether or not you were done typing, and you'd invariably lose track of what your input line looked like. So the primary task of a TinyMUD client was to separate them. Some used a "split screen", and some just kept refreshing the input line as new output was displayed.
None of our MUDs ever appeared on port 23 and none of our servers ever spoke "The TELNET Protocol" as found in RFC 854. Telnet was simply the bundled TCP client that you could use for anything.
The other cool features for a MUD client was using macros to perform repeated tasks or say interesting things, and /hilite and /gag were indispensable. /gag silenced/muted a player or a pattern-match of your choice, and so to play with "raw telnet" was to unblock all your /gagged players and let them get under your skin again. A fate truly worse than death (well you got paid "insurance" for dying, so many people enjoyed the experience.)
Also popular in Tiny* clients was cursor line-editing and a command history. One client developer was sort of a troll, and so when he forked "tinywar" it began to feature some automation that could permit a player to make a real nuisance of themselves. But he was also a great programmer, and not all tinywar users were trolls, so it got put to good use.
Ultimately, Explorer_Bob wrote TinyFugue, and Ken Keys "Hawkeye" took over development, pushing it into amazing heights on a level with MUSH programming, and TinyFugue basically became the gold standard client for Unix and was also ported to Win32, and ultimately abandoned in an extremely stable state. I went to school with Ken. Miss you, man!
I had to use a VMS system which had different telnet behavior (staircasing due to CR/LF mismatch) and originally used a locally developed client (TINT mentioned here https://www.linnaean.org/~lpb/muddex/clients.html) then learned C to write a subsequent client (DINK) which supported macros and "portals"- an early way to transit across different MUDs. A few years ago I learned that DINK was forked and improved- my early C code was awfully bad. It's still bad, but it was awfully bad then.
The one funny bit is that I copied TINT's exit command (Control-Y) instead of using /quit which led to several years of email complaints form folks who couldn't exit the mud (in those days, you usually just had one terminal connection, and if you couldn't exit a program, you had to forcibly disconnect the modem).
I'm sure several MUDs did this, but, this sounds an awful lot like my home MUD of Achaea, which started in ~1997, still exists (healthily!), and has this exact system :)
OK to be fair it might not be THE telnet protocol but still.
Eg: `telnet some.http.addr 80` and then type in `GET /index.html HTTP/1.0` and hit enter twice.
You can use it to test SMTP servers too.
[0]: https://assets.denon.com/documentmaster/us/heos_cli_protocol...
Right?
I do remember reading a long time ago telnet does/can support encryption. But when I looked at the systems I have access to, the manuals have no mention of that.
Also - SSH offers more than just encryption, but also data integrity - you can modify / manipulate a telnet session in ways you just can’t via SSH
(I do run Wireguard, it just feels like sometimes a VPN is a sledgehammer to solve a port forwarding problem)
You know what wireguard is?
> If telnet can use keypairs
Kerberos exists, so, yes, it can.
> You know what wireguard is?
I suppose if you prefer, I can write "over the network". The point is that the password leaves my machine. As a practical example: With password auth, if an attacker gets root on a server then they can read your password and log in to other machines. With SSH keypairs, this isn't possible (unless you go out of your way to forward an SSH agent, and even then there are mitigations).
>> If telnet can use keypairs
> Kerberos exists, so, yes, it can.
This sounds promising, and in fact at least one page I found about it claims that kerberos+telnet encrypts the session, at which point I don't immediately see what we need wireguard or ssh for. On the other hand, it looks like eg. GNU inetutils telnet doesn't support it? In fact, https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-us... says
> The Kerberos V5 telnet command works exactly like the standard UNIX telnet program, with the following Kerberos options added:
which makes it sound like they've just made a special telnet variant with these features, at which point it rather feels like we've just re-invented ssh under a different name.
Which is just an abstraction of a password. Instead of storing it in your mind and sending it over the network you store it on your harddrive and use to calculate things on the network. Haven't you just moved the security boundary slightly? You're now also mixing up authentication and encryption into one package which isn't strictly an upside. Granted you can secure your key with a password or a yubikey but now you're messing with agents or you're typing that password an incredible amount.
I see your point. The dead simplicity of telnet session over encrypted tunnel still appeals to me in the face of the structures above. It also means you can elide the whole "how do I do this complicated port forwarding with ssh" question entirely.
> we've just re-invented ssh under a different name.
ssh is the best implementation of self signed security you can get. With kerberos we actually get a central authority and it separates authentication and encryption rather nicely without requiring user agents running as daemons.
I don't think that's functionally true. The important thing is that with telnet or password-auth ssh, you send the actual text of your password to the server. With ssh keys, the server and client do some magic crypto math to let you prove you control the private key without ever sending it. Therefore, a compromised server can steal a password, but not a ssh key.
(Yes, in theory perhaps you could do some fancier way of proving that you know a password without sending it, but 1. I'm no cryptographer, but the fact that openssh hasn't done this feels suggestive, and 2. that is once again a pretty big change for the nominal goal of keeping telnet)
> ssh is the best implementation of self signed security you can get. With kerberos we actually get a central authority and it separates authentication and encryption rather nicely without requiring user agents running as daemons.
Sure. Like, I've never thoroughly evaluated kerberos in depth (again, I'm no cryptographer), but I hear generally good things. My point is that by the time you have kerberos, you aren't really using what I would call telnet anymore, you're using something that acts like telnet but backs into a completely different authentication and communication system, and at that point you might as well use a completely different authentication and communication system without pretending to be telnet. This goes double because (open)ssh does support kerberos.
This use case is perfectly secure, because IBM mainframe/midrange telnet servers support telnet-over-TLS, and that’s what people run in production
For connecting to mainframes, SSH has no real advantage over TLS, and its major disadvantage is that there is no standardised way to transmit 3270/5250 data streams over it
But people looking for telnet traffic over the public Internet probably won’t even notice this, because they aren’t looking for telnet over TLS - which is difficult to distinguish from whatever else over TLS - and because almost all of it goes over VPNs not the public Internet
The two entities which have reported on this event are looking for tcp traffic on port 23, not TELNET protocol traffic. So indeed, as you say, if they are tunneled in VPN, or encapsulated or using an alternate port, tn3270 traffic will not be detect on port 23/tcp. Telnet over TLS is assigned to port 992, so any RFC-compliant implementation would be found there, and irrelevant, again, to the telnetd CVE reported this year.
There are two facets to January's incident: the vulnerability in the GNU implementation of telnetd, and the purported, widespread blocking of port 23. The original report went out because of the coincidence they perceived there, and especially because the latter preceded the disclosure of the vulnerability!
Mainframe tn3270 servers would not be subject to this vulnerability. If there had been a port filter in place, it only would've tripped-up the mainframes that still used port 23, which is evidently optional, and it says here that many admins want to keep AIX's telnetd bound to port 23 anyway.
So it is good to know that TELNET protocol, and its extensions, are alive and well. We may not actually know how many clients and servers implement the protocol itself, since MUDs made this a routine thing, but certainly the deployment of IBM systems is formidable, considering the sheer mass of the iron in their rack mounts.
And IMO, X.509 (used in TLS) is virtually superior over SSH’s bespoke certificate format in every way. You get both regular certificate pinning (like what SSH uses now) AND full certificate authority chains (if you want).
The main downside is that X.509 is more complex.
It doesn't do full chains, but SSH does have certificate authorities. I agree that the lack of intermediate CAs is a limitation (a CA can only sign a leaf node public key directly), but it's still super useful.
If you have a well secured LAN where trust is social SSH gets you nothing. SMTP telnet http being plain were from days when users were able to actually reason about what was happening within their OS. If there’s anything that should be scoffed at its us now with our bloated opaque corporate controlled OSes.
Maybe I should get in on this grift. Curl American Patriot Gold Marine Corps Never Forget 9/11 Edition for only $200. Loads _any_ URL.
About 20 years ago I worked on backend stuff for the sales site for a well-known UK retailer that advertised their spiffy new web store on TV.
Part of the TV ad had a couple of smiley young people with Techie Girl typing on a computer, and a big animated padlock swooping in and clicking shut and Mumsy Middle-Aged Manager smiling happily, and cut to Hacker Guy typing furiously in a darkened room as a big padlock pops up on the screen and "SECURITY LOCKED" popping up, as he scowls at the screen. The VO was something like "and it's safe to buy online - our site has Security Built In" <fx: heavy padlock clunks shut>
This sequence - the animation and filming this part right their in our own web dev office - cost over five grand of mid-2000s money to make, most of which being the padlock animations. The clunk was my bike lock.
£5000. Five Thousand Pounds.
I can tell you they spent well under 1/20th of that in developer time to actually write the security code for the site. It didn't even use HTTPS, which was kind of a requirement even in 2006.
"no one ever went broke underestimating the taste or intelligence of the US public" - HL Mencken
I looked into their Support documentation and it explains how to run the app, not how it works.
I read a 2-slide "Whitepaper" and it describes the many advantages and sort of tells you how it starts in "Ring 0" and the TPM and uses public-key cryptography, but not how it works.
They have trademarked KTLS™, but Kernel TLS is also an extension of actual TLS into the Linux kernel, so good luck differentiating that. Isn't it fun how you can trademark your trade secrets, but if you attempt to patent them, that means public disclosure.
If I had to hypothesize about it, I'd say that there is a Ring 0 hardware driver that takes the USB data, encrypts it, and the encrypted data is tunneled to each application, where it is somehow decrypted transparently without modifying any of the user's applications.
I would research this more in-depth but gnomes have already stolen my underpants. UUU~~U~~~U+++ATH0+++ NO CARRIER
Unless you're doing automatic and mandatory SSH key rotation (which almost nobody ever does) then SSH is just "password on a sticker next to the monitor" with a long password.
I've had this conversation recently with a "Cyber Architect" who was losing his shit over SNMPv1 on our network passing community strings as plaintext.
Yes. If you sniff the traffic you can see the read-only password, which is left as default, and from that you can deduce that the ODU temperature for the microwave link is 32°C at the moment (pretty toasty for 3° outside air temperature). Big Fucking Whoop.
Concentrate on not having "bad actors" sniffing traffic on our network.
If the burglar is in your kitchen eating your sandwich out of the fridge, the problem is that the burglar is in your kitchen, not that he's eating your sandwich.
A burglar isn't going to hack your lock. He's going to smash your door or window and steal whatever he can get his hands on
How does one do a measurement of traffic like this? You would have to own the nodes in the packet route to be able to see traffic, but TerraceNetworks or GreyNoise don't seem to be companies that do that. How do they get the data to analyze?
They have them all over the world to get attackers scanning only certain regions etc.
I should also note - I’m extremely skeptical of the OPs claims or inference that the attackers have potentially fingerprinted greynoises sensors. To suggest this while some traffic increased from specific ASN’s seems unlikely that this was the case.
If it’s not clear - this was written by a competitor of theirs.
Also I just found "Hawkeye" the author of TinyFugue, Ken Keys, employed here! Cool beans!
When looking at telescope data like CAIDA’s UCSD-NT, it’s also important to remember that source IPs can be spoofed absent a valid handshake, something that both our and GreyNoise’s analysis accounts for.
No one is stopping you from using the telnet client. And really you should just use netcat
http://isabevigodadead.com/ [That's right, kids. There is no HTTPS server.]
The Day the Telnet Died
I thought it was, and posted this same comment on the other telnet article. But I was informed that it is back! And I was able to confirm it myself.
I don't have a telnet client on my Mac, but I was able to confirm with nc.
nc towel.blinkenlights.nl 23