Earlier quoted context omitted.
Well this is weird. You talk about me, my, mine, my network, my computer. But you're promoting a "distro". That means you're distributing software. It's not yours anymore. Attackers on a network will use techniques to "pivot". Once a "foothold" is established then they scan for other places to attack. They will indeed get inside "your" computer, or router, and then compromise your telnetd. It comes back to the libert…
[flagged]
The Day the Telnet Died
381–390 of 414 posts
Re: The Day the Telnet Died
#382Earlier quoted context omitted.
SSH certs aren't TLS certs. Totally different format. All SSH CAs are private, you run your own CA to issue certs to devices you want to allow to connect to your server.
It's... not about the file format. The point is that a "private" cert is not a "cert" as commonly understood. The important part to a certification authority is the AUTHORITY part, not the data format. Either there is a trusted third party that will promise you are who you say you are, or there is not. With SSH, there is not, nor can there be as it is commonly deployed. So applications that want that have used other…
Re: The Day the Telnet Died
#383Never 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.
> 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…
This is still true, though 5-10 minutes is slightly pessimistic. Source: https://youtu.be/6uSVVCmOH5w
TL;DW - Guy installs XP and makes it internet accessible, only takes 15 minutes before the first malware appears on it.
Re: The Day the Telnet Died
#384Earlier quoted context omitted.
Changes like these lend even more credibility to the approach of putting everything on port 443 over TLS, and distinguishing protocols based on hostname / HTTP path.
If everything was on port 443 why would we even need ports. The ports are there for a reason, it is idiotic to serve everything over http as you would need a mechanism to distinguish the different flows of traffic anyhow.
Reverse proxies can disambiguate based on the SNI. I could run telnetd on port 23, but have port 23 firewalled off, and have my reverse proxy listening on port 443 with TLS forward anything going to telnet.mydomain.com to telnetd. Obviously, my client would need to support that, but a client-side proxy could easily handle that just as well.
Re: The Day the Telnet Died
#385Earlier quoted context omitted.
There's no UNIX requirement for telnet. Ubuntu does not include it by default (starting 16.04?). Most most distros don't.
Two wrongs don't make a right. Apple still includes uucp for some unknown reason. The saving disk space argument makes no sense because telnet was one of the smaller binaries in /usr/bin. Telnet continues to be widely used for select use cases and being told we're naughty by not including it feels punitive and just adds extra steps. What are you supposed to do, trash a $1m piece of industrial equipment because Apple…
It just isn’t installed by default when 99% of users have no desire for it.
Re: The Day the Telnet Died
#386Earlier quoted context omitted.
That's crazy. This is core business critical software but they just YOLO critical changes without any automated tests? this PR would be insta-rejected in the small SAAS shop I work at.
Most 90’s era software had zero tests. Nobody gave it a second thought.
As a data point, my first tech job was QA for a COBOL compiler vendor. They supported roughly 600 permutations of architecture, operating system, and OS version with a byte-coded runtime and compiler written in C. I maintained a test runner and suite with many thousands of tests, ranging from unit tests to things like Expect UI tests. This was considered routine in the compiler vendor field, and in the scientific computing space I moved into. I worked with someone who independently reproduced the famous Pentium FDIV bug figuring out why their tests failed, which surprised no one because that was just expected engineering.
Then you had the other end of the industry where there was, say, 50k lines of Visual Basic desktop app where they didn’t even use version control software. At a later job, I briefly encountered a legacy system which had 30 years of that where they had the same routine copied in half a dozen places, modified slightly because when the author had fixed a bug they weren’t sure if it would break something else so they just created a copy and updated just the module they were working on.
Re: The Day the Telnet Died
#387Earlier quoted context omitted.
Most 90’s era software had zero tests. Nobody gave it a second thought.
This is quite untrue as a blanket statement. The problem is that there was massive cultural variation: if you installed a Perl module from CPAN you probably ran hundreds of tests. If you ran a C program, it ranged from nothing to “run this one input and don’t crash” to exhaustive suites. PHP tended towards nothing with a handful of surprises. As a data point, my first tech job was QA for a COBOL compiler vendor. They…
Re: The Day the Telnet Died
#388Earlier quoted context omitted.
Changes like these lend even more credibility to the approach of putting everything on port 443 over TLS, and distinguishing protocols based on hostname / HTTP path.
If everything was on port 443 why would we even need ports. The ports are there for a reason, it is idiotic to serve everything over http as you would need a mechanism to distinguish the different flows of traffic anyhow.
Protocol multiplexing/demultiplexing is a feature of software like sslh, nginx, and HAProxy exist, and they don't need to listen on multiple ports to speak multiple protocols or connect multiple services. Many advanced reverse proxies can do this with stream sniffing of some flavor.
People already do actually run everything through port 443 simultaneously.
Re: The Day the Telnet Died
#389Earlier quoted context omitted.
I can connect with the GNU telnet client via the Spectrum ISP to servers in both Seattle and the Netherlands.
It doesn’t matter what client you use. Is it on port 23/tcp, and what are the ASNs? The report specifically says that cloud networks like VPS, AWS seemed exempt.
From ASN AS11427 (Charter Communications Inc) to ASN AS12859 (BIT BV) and to ASN AS14361 (HopOne Internet Corporation)
(edit: formatting)
Re: The Day the Telnet Died
#390Earlier quoted context omitted.
Netcat works as a telnet client. GAWK can do that too with a dumb loop. So can con(1) under 9front.
Using netcat results in showing Unicode replacement symbols, instead of answering to telnet options. I doubt it implements telnet at all, because this is just not its job.
> If netcat is compiled with -DTELNET, the -t argument enables it to respond to telnet option negotiation [always in the negative, i.e. DONT or WONT]. This allows it to connect to a telnetd and get past the initial negotiation far enough to get a login prompt from the server. Since this feature has the potential to modify the data stream, it is not enabled by default. You have to understand why you might need this and turn on the #define yourself.