Protocol Verification and Tunnelling

Circuit level tunneling for instance perhaps SOCKS or SSL tunneling allows a proxy server to pass any protocol it requires.  Of course at  this level the gateway may not actually understand the protocol it is passing, it certainly will not be able to understand what is happening and detect any but the most basic error states.  It is incredibly useful though for any server administrator who needs to cope with an ever expanding list of protocols and services through a gateway.

Take for instance the SSL tunneling protocol, you can really ignore it’s name to some extent as it’s capable of handling any protocol at all as long as it’s TCP based.  For example suppose you need to allow logons to an ancient library system using telnet – then the SSL protocol will allow it to work seamlessly.  Obviously it will also help with some of the inherent dangers of using the extremely insecure plain text Telnet login!

But allowing this generic tunneling means you have another security issue – verification of the protocol that is being used. One method of trying to instill some security is to firstly only allow services and protocols that use well known ports.  If they’re not on one of these then don’t allow them to be tunneled.  For instance you could allow 443 for HTTPS, 636 for LDAP, 465 for SMTPS, 990 for Secure FTP and so on.  This gives you some control over what protocols and services run through the tunnel.

However this is of course not ideal for one simple reason, that those are only suggested ports for most of the services.  There’s little to stop me running my IRC chat service on 636 to simulate LDAP and allow the protocol through.  I have seen people running a commercial Polish proxy on a University server in Warsaw simply by emulating HTTPS traffic.  Administrators are often very hesitant to block these ports purely because it can cause havoc if your internet gateway suddenly starts blocking all secure HTTP sites.

There is another fact that helps with reducing exploitation risks – protocols that are proxied at the application layer – such as HTTP, FTP and Gophur don’t actually create direct tunnels between the specific ports.  Here the proxy is actively managing the protocol and not blindly forwarding it into a black hole.