Comment by da_chicken
7 days ago
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.
> 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.