Depending on the environment and the purpose of a proxy then protocol verification is not always necessary. Indeed this was mostly ignored by earlier proxies and gateways as information was simply tunneled through transparently. Nowadays though there is normally some requirement to identify the protocol being transmitted through the proxy server.
Generic (circuit-level) tunneling, such as SOCKS and (SSL) tunneling, allows any protocol to be passed through the proxy server gateway. This implies that the proxy server does not necessarily understand the protocol and cannot verify what is happening at the protocol level. For example, the SSL tunneling protocol, despite its name, can tunnel /my TCP-based protocol, for example the telnet protocol.
A short-term solution to this is to allow only well-known ports to be tunneled, such as 445 for HTTPS, 563 for SNEWS, and 636 for secure LDAP. See Table 7-1 on page 135 for a list of well-known Web-related protocol ports. A longer-term solution is to be provided by proxy servers that verify the spoken protocol. More intelligence will need to be built into proxy servers to understand even protocols that are merely tunneled, not proxied. This enables proxies to notice misuse, such as exploiting the SSL tunneling to establish a telnet session.
Note that protocols that are proxied at the application level by the proxy server, such as HTTP, FTP, and Gopher, cannot be exploited as above because no direct “tunnel” is established through the proxy server. Instead, the proxy will fully re-perform the request on behalf of the client and then pass the response back. This is important as it may be necessary for the function to be completed properly. For example it’s common now to stream multimedia or video through the servers and these need to function on the specific ports. You won’t be able to stream things like the BBC TV output through this site without some sort of protocol verification taking place.
This ensures that the protocol is a legitimately allowed protocol. ‘ However, the Gopher protocol, or rather Gopher URLs, can be used to fool the proxy to make requests using other protocols by crafting special malicious URLs that convert to the language used by some other protocol.
Common Security Holes in Server Software can be read about on this blog and particularly there are Trojan horses disguised as Gopher URLs. If limiting to well-known ports is not acceptable (there are a number of servers out there running on non-standard ports), it is recommended to at least [9106/e ports that deﬁnitely should not be allowed an SSL tunnel to. Among these are ports known to be dedicated for other purposes, such as the telnet and SMTP ports (23, 25, respectively). Some proxy server software may in fact have a built-in ﬁlter for these ports and automatically disallow Gopher requests to them.