Comment by miki123211
7 days ago
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.
7 days ago
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.
Wireguard over 443/udp is also a neat trick. No need to make it look like quic although I wouldn't be surprised if someone takes the effort to make it that stealthy.
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 will use it against us, or we can accept the chaos that results from abandoning it.
> 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).
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.
1 reply →
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.
1 reply →