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

401–410 of 414 posts

Re: The Day the Telnet Died

#401

Post by gerdesj »

gerdesj wrote: post #397
Twisol wrote: post #11

Earlier quoted context omitted.

The difference between "telnet" the program and "telnet" the protocol is especially important in this discussion, I think. A more "proper" tool for that is netcat -- I doubt SMTP supports the Telnet option negotiations subsystem. (I also doubt SMTP servers can interpret the full suite of Network Virtual Terminal (NVT) commands that the Telnet protocol supports.) There's clearly enough similarity between the two proto…

When I find nc on a customer's Windows box, I'll be sure to use it 8)

Oh and I did mention swaks. nc comes from a time when SSL was a newish thing. swaks can do TLS with nobs on.

Re: The Day the Telnet Died

#402

Post by 7bit »

trashb wrote: post #294
7bit wrote: post #220

Earlier quoted context omitted.

Censorship is one of these words that get slapped on anything. Filtering one port is not censorship. Not even close.

> censorship, the suppression or removal of writing, artistic work, etc. that are considered obscene, politically unacceptable, or a threat to security It is not the responsibility of the Tier 1 or the ISP to configure your server securely, it is their responsibility to deliver the message. Therefore it is an overreach to block it because you might be insecure. What is next. They block the traffic to your website bec…

I don't agree with your argument, but I don't want to debate that.

But let's say I agree: That still is not censorship.

Re: The Day the Telnet Died

#403

Post by trashb »

da_chicken wrote: post #388
trashb wrote: post #290

Earlier quoted context omitted.

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.

Yeah, that already exists. 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.

Protocol multiplexing exists. But you will have to agree on a single protocol, which I view as impossible since different applications have different requirements.

If you route all your traffic through https that comes with all the upsides, for example the security layer (ssl). But also the downsides of for example overhead of headers. Currently we have an overarching (network layer) protocol, it is called IP. It divides the traffic into different ports at the host, these ports speak different protocols. If you move the multiplexing higher up the OSI stack, you are violating the principles of separation and making your stack less flexible, you are mixing OSI layers 4: transport up to 6: Presentation. Conflicting these layers can lead to big problems as this includes things like the Transport layer, for example the difference between udp/tcp is included there.

The beauty of the network stack is that there are certain layers that separate responsibility. This allows the stack to apply to wildly different scenarios. However I do agree that there should be no filtering applied on behalf of the customers.

Re: The Day the Telnet Died

#404

Post by trashb »

Sohcahtoa82 wrote: post #384
trashb wrote: post #290

Earlier quoted context omitted.

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.

You've got it wrong. It doesn't have to be HTTP[S] traffic. 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.

Yes you can run any service on any port. But tunneling telnet over another protocol seems like you would just move the problem. I don't know too much about SNI but if "Reverse proxies can disambiguate based on the SNI" wouldn't your network service provider also be able to filter based on SNI?

You would need to agree on a protocol and you would gain all the advantages but also the disadvantages of the tunneling protocol.

Re: The Day the Telnet Died

#405

Post by trashb »

allknowingfrog wrote: post #308
trashb wrote: post #290

Earlier quoted context omitted.

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.

Preventing the traffic from being distinguished is the whole premise. Port 23 gets blocked because everyone uses it for telnet, and everyone expects bad actors to know that. If everything moves to 433, we'll end up with a variety of routing systems and no focal point for attack. The only alternative is to disallow port filtering in core internet infrastructure. We can either have a standard and accept that bad actors…

> The only alternative is to disallow port filtering in core internet infrastructure

I think this is an acceptable alternative. In the same way that your mail service is legally required to deliver your mail as part of their universal service obligation (without reading it).

Re: The Day the Telnet Died

#406

Post by Sohcahtoa82 »

trashb wrote: post #404
Sohcahtoa82 wrote: post #384

Earlier quoted context omitted.

You've got it wrong. It doesn't have to be HTTP[S] traffic. 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.

Yes you can run any service on any port. But tunneling telnet over another protocol seems like you would just move the problem. I don't know too much about SNI but if "Reverse proxies can disambiguate based on the SNI" wouldn't your network service provider also be able to filter based on SNI? You would need to agree on a protocol and you would gain all the advantages but also the disadvantages of the tunneling proto…

> wouldn't your network service provider also be able to filter based on SNI?

Two things:

1. Only if they knew that the hostname in question is indeed being used for telnet tunneling. You can set that host name to whatever you want.

2. Encrypted SNI is a thing.

> You would need to agree on a protocol and you would gain all the advantages but also the disadvantages of the tunneling protocol.

Yeah, admittedly the entire thing is a bit contrived. If your client is capable of speaking the tunneling protocol, then likely you'd just use the tunneling protocol itself, rather than using it to tunnel telnet.

Re: The Day the Telnet Died

#407

Post by Sohcahtoa82 »

trashb wrote: post #403
da_chicken wrote: post #388

Earlier quoted context omitted.

Yeah, that already exists. 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.

Protocol multiplexing exists. But you will have to agree on a single protocol, which I view as impossible since different applications have different requirements. If you route all your traffic through https that comes with all the upsides, for example the security layer (ssl). But also the downsides of for example overhead of headers. Currently we have an overarching (network layer) protocol, it is called IP. It div…

> Protocol multiplexing exists. But you will have to agree on a single protocol

I may be misunderstanding your message here, but the requirement to agree on a single protocol isn't true when you're using multiplexing. I think you're confusing tunneling with multiplexing.

With multiplexing, you have multiple protocols listening on a single port. The multiplexer server sniffs the first few bytes of what the client sends to determine what protocol is being used, then decides which back-end to forward the connection to.

Neither the client nor the final back-end need to be aware that multiplexing is happening, and likely aren't.

Through this, you can use both HTTPS and Telnet on port 443 without the Telnet client needing to have any changes done.

Re: The Day the Telnet Died

#408

Post by [deleted] »

emmelaich wrote: post #146
taftster wrote: post #103

Earlier quoted context omitted.

How do you automate, for example, "HTTPS over websocket with OAuth", without providing some kind of hard-coded, static or otherwise persistent authentication credentials to the calling system in some form (either certificate based auth, OAuth credentials, etc.)? The problem with IoT and embedded secrets isn't really a solved problem, from what I can tell. I'm not sure that OAuth exactly solves the problem here. Thoug…

The manufacturer should at least supply certificates, and it could be up to you to ignore or use. It's not much but it's something.

[deleted]

Re: The Day the Telnet Died

#409

Post by JasonADrury »

1718627440 wrote: post #243
prmoustache wrote: post #227

Earlier quoted context omitted.

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

The telnet client comes with MS Windows, Linux and macOS. The only platforms were you need to install some extra component are Android and iOS.

Are you sure? I can't seem to find the Linux implementation anywhere in the repo https://github.com/search?q=repo%3Atorvalds%2Flinux%20telnet...

Re: The Day the Telnet Died

#410

Post by 1718627440 »

JasonADrury wrote: post #409
1718627440 wrote: post #243

Earlier quoted context omitted.

The telnet client comes with MS Windows, Linux and macOS. The only platforms were you need to install some extra component are Android and iOS.

Are you sure? I can't seem to find the Linux implementation anywhere in the repo https://github.com/search?q=repo%3Atorvalds%2Flinux%20telnet...

You are absolutely right: s|Linux|GNU/Linux|
Post reply on HN