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.
> 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.
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.