My understanding is that application level gateways restrict the traffic they proxy based on port and protocol - say HTTP over port 80 or MQTT over port 1883. Both types of traffic are using TCP as the transport but a different protocol. Is there any security benefit to this? I can't think of any way that restricting the protocol on a port makes it more secure.
This is a follow up question to this one which I understand to say that there's no benefit.
Traffic inspection (particularly for Application Filtering).
If I am an employer and I keep HTTP proxy logs of the websites you visit (and block some of the undesirables on work-time such as Facebook), I don't want you connecting to a VPN or other SOCKS proxy and bypassing my restrictions or uploading my confidential business information which is why I've bothered to lock down which TCP/UDP ports can be used in the first place because you happen to know that TCP port 80 is a free-for-all on our firewall.
So while on a firewall I may typically block everything from the workstations to the Internet apart from port 80.. but then you go and find a proxy that is running on port 80 to connect to.. ensuring that the only traffic going through is valid HTTP traffic ensures I can inspect and malware scan it.
Additionally I don't want you connecting to BitTorrent clients on TCP Port 80 and using my network connection for BitTorrent.
I agree with the commenter that Application Layer Inspection is not terribly common. There are too many ports for various applications in use now (particularly on mobile devices) and too many proprietary protocols floating around (which I speculate is perhaps one of the reasons Microsoft decided to bin Forefront TMG, they probably got bored of writing the application filters) that Application Layer Inspection is often too restrictive for most environments and causes more support issues than it's worth (verses the small number of people that would try and have the technical knowledge to exploit my firewall rules).
What'sApp will try to connect on TCP port 443 (typically used by TLS) over its own weird protocol (i.e. NOT TLS) to specifically bypass any firewalls that don't allow its usual port of TCP port 5222.
Finally, encrypted connections won't typically reveal what the application is anyway (Is my TLS connection one to a web-server or to my mail-server or to a TLS VPN?) and a blind "Allow all TLS traffic on TCP port 443" rule still leads you open to some abuse unless you have some TLS Visibility appliance.
You may also want to look at Application Level Filters section of the Stateful Firewall article and its associated Application Firewall article on Wikipedia.
... never open a socket to "any" protocal,...
A socket gets opened by an application to accept data for a specific protocol, because this is just how applications work. No application would accept "any" data because it simply does not know how to handle these data, i.e. it has only implemented a specific communication protocol like HTTP, SMTP etc. The port for the socket is similar to the number of the house in the street, i.e. it is simply part of the complete address of a service.
If you are instead talking about firewalls: simply port filtering firewalls do not use sockets at all but simply pass or block packets based on the port given in the TCP/UDP packet. And application level gateways (proxies) use sockets but there task is to filter traffic for a specific protocol, so again they are only able to speak this specific protocol and not "any".
